[PATCH] MAINTAINERS: Update Chun-Kuang Hu's email address
Update my email address to @kernel.org Signed-off-by: Chun-Kuang Hu --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 38fe2f3f7b6f..dceaeebce52a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5607,7 +5607,7 @@ F:include/uapi/drm/lima_drm.h T: git git://anongit.freedesktop.org/drm/drm-misc DRM DRIVERS FOR MEDIATEK -M: CK Hu +M: Chun-Kuang Hu M: Philipp Zabel L: dri-devel@lists.freedesktop.org S: Supported -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 02/16] drm/i915: Clear the repeater bit on HDCP disable
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.5.8, v5.4.24, v4.19.108.
v5.5.8: Build failed! Errors:
drivers/gpu/drm/i915/display/intel_hdcp.c:780:2: error: implicit
declaration of function âintel_de_writeâ; did you mean
âintel_sbi_writeâ? [-Werror=implicit-function-declaration]
drivers/gpu/drm/i915/display/intel_hdcp.c:781:10: error: implicit
declaration of function âintel_de_readâ; did you mean âintel_sbi_readâ?
[-Werror=implicit-function-declaration]
v5.4.24: Failed to apply! Possible dependencies:
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.108: Failed to apply! Possible dependencies:
0e39037b3165 ("drm/i915: Cache the error string")
16e4dd0342a8 ("drm/i915: Markup paired operations on wakerefs")
39e2f501c1b4 ("drm/i915: Split struct intel_context definition to its own
header")
408bd9178666 ("drm/i915: extract intel_hdcp.h from intel_drv.h")
52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context
interrupt tracking")
538ef96b9dae ("drm/i915/gem: Track the rpm wakerefs")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
6b048706f407 ("drm/i915: Forcibly flush unwanted requests in drop-caches")
87f1ef225242 ("drm/i915: Record the sseu configuration per-context &
engine")
95fd94a645f7 ("drm/i915: avoid rebuilding i915_gpu_error.o on version
string updates")
c0a6aa7ec2c3 ("drm/i915: Show actual alongside requested frequency in
debugfs/i915_rps_boost_info")
c2400ec3b6d1 ("drm/i915: add Makefile magic for testing headers are
self-contained")
c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs,
v6")
e0516e83640e ("drm/i915: Move sandybride pcode access to intel_sideband.c")
e1ef734eaec5 ("drm/i915: make intel_frontbuffer.h self-contained")
e6154e4cb8b0 ("drm/i915: Skip the ERR_PTR error state")
eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and
error capture")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 01/16] drm/i915: Fix sha_text population code
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.5.8, v5.4.24, v4.19.108.
v5.5.8: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging
macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
v5.4.24: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging
macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.108: Failed to apply! Possible dependencies:
04707f971636 ("drm/i915: Initialize HDCP2.2")
09d56393c1d8 ("drm/i915: hdcp1.4 CP_IRQ handling and SW encryption
tracking")
2f80d7bd8d93 ("drm/i915: drop all drmP.h includes")
33b7f3ee6e00 ("drm/i915: Add CRTC output format YCBCR 4:2:0")
340a44bef234 ("drm/i915/icl: program MG_DP_MODE")
342ac601df64 ("drm/i915: hdcp_check_link only on CP_IRQ")
47658556da85 ("drm/i915/dp: Do not grab crtc modeset lock in
intel_dp_detect()")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
668b6c176c33 ("drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON")
7b610f1fbed2 ("drm/i915/dp: Add DSC params and DSC config to
intel_crtc_state")
9055aac76589 ("drm/i915: MEI interface implementation")
9844bc87cb7a ("drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ handling")
bdc93fe0eb82 ("drm/i915/debugfs: hdcp capability of a sink")
cbfa8ac835cb ("drm/i915/dp: Kill intel_dp->detect_done flag")
d3dacc70797b ("drm/i915: wrapping all hdcp var into intel_hdcp")
d5acd97f5571 ("drm/i915/dp: Use a local variable for intel_encoder *")
d78aa650670d ("drm: Add drm/drm_util.h header file")
de25eb7f3075 ("drm/i915: introduce dp_to_i915() helper")
f106d1005ac7 ("drm/i915: Pullout the bksv read and validation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206781] GM104 (GeForce 840m) with many errors "fifo: SCHED_ERROR 20"
https://bugzilla.kernel.org/show_bug.cgi?id=206781 Ilia Mirkin (imir...@alum.mit.edu) changed: What|Removed |Added CC||imir...@alum.mit.edu --- Comment #1 from Ilia Mirkin (imir...@alum.mit.edu) --- As mentioned on IRC, the MMIO faults at the start aren't anything to worry about. These two I've never seen before: nouveau :07:00.0: fifo: fault 01 [WRITE] at 0015 engine 05 [BAR2] client 08 [HUB/HOST_CPU_NB] reason 02 [PTE] on channel -1 [007fd38000 unknown] nouveau :07:00.0: fifo: fault 01 [WRITE] at engine 05 [BAR2] client 08 [HUB/HOST_CPU_NB] reason 0a [UNSUPPORTED_APERTURE] on channel -1 [007fd38000 unknown] And the SCHED thing is most frequently due to the ctxsw firmware timing out or other error. But given the faults above, could easily be follow-on from that. -- 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
[Bug 206781] New: GM104 (GeForce 840m) with many errors "fifo: SCHED_ERROR 20"
https://bugzilla.kernel.org/show_bug.cgi?id=206781 Bug ID: 206781 Summary: GM104 (GeForce 840m) with many errors "fifo: SCHED_ERROR 20" Product: Drivers Version: 2.5 Kernel Version: 5.4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: gse...@gmail.com Regression: No Created attachment 287821 --> https://bugzilla.kernel.org/attachment.cgi?id=287821&action=edit dmesg contining errors - shortend at end Laptop HP Envy 15 with i7-4700mq and GeForce 840m on Ubuntu 18.04 and 20.04. nouveau outputs many megabytes into system logs (kern.log and syslog) with "nouveau :07:00.0: fifo: SCHED_ERROR 20 []" full log is in attachment some relevant output before "SCHED_ERROR" nouveau :07:00.0: NVIDIA GM108 (118010a2) ... nouveau :07:00.0: bios: version 82.08.14.00.0e ... nouveau :07:00.0: fb: 2048 MiB DDR3 nouveau :07:00.0: bus: MMIO read of FAULT at 6013d4 [ IBUS ] ... nouveau :07:00.0: bus: MMIO read of FAULT at 10ac08 [ IBUS ] nouveau :07:00.0: fifo: fault 01 [WRITE] at 0015 engine 05 [BAR2] client 08 [HUB/HOST_CPU_NB] reason 02 [PTE] on channel -1 [007fd38000 unknown] nouveau :07:00.0: fifo: fault 01 [WRITE] at engine 05 [BAR2] client 08 [HUB/HOST_CPU_NB] reason 0a [UNSUPPORTED_APERTURE] on channel -1 [007fd38000 unknown] vga_switcheroo: enabled [TTM] Zone kernel: Available graphics memory: 8164024 KiB nouveau :07:00.0: fifo: SCHED_ERROR 20 [] nouveau :07:00.0: fifo: SCHED_ERROR 20 [] nouveau :07:00.0: fifo: SCHED_ERROR 20 [] ... I have also reported here: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/522 -- 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 10/22] drm/mediatek: Use simple encoder
On 05/03/2020 16:59, Thomas Zimmermann wrote:
> The mediatak driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Matthias Brugger
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
> 2 files changed, 6 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 14fbe1c09ce9..9c90c58e5acd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_dpi_regs.h"
> #include "mtk_drm_ddp_comp.h"
> @@ -509,15 +510,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> return 0;
> }
>
> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> - .destroy = mtk_dpi_encoder_destroy,
> -};
> -
> static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> @@ -596,8 +588,8 @@ static int mtk_dpi_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> - ret = drm_encoder_init(drm_dev, &dpi->encoder, &mtk_dpi_encoder_funcs,
> -DRM_MODE_ENCODER_TMDS, NULL);
> + ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
> + DRM_MODE_ENCODER_TMDS);
> if (ret) {
> dev_err(dev, "Failed to initialize decoder: %d\n", ret);
> goto err_unregister;
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0ede69830a9d..a9a25087112f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_drm_ddp_comp.h"
>
> @@ -787,15 +788,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> dsi->enabled = false;
> }
>
> -static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
> - .destroy = mtk_dsi_encoder_destroy,
> -};
> -
> static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> @@ -888,8 +880,8 @@ static int mtk_dsi_create_conn_enc(struct drm_device
> *drm, struct mtk_dsi *dsi)
> {
> int ret;
>
> - ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
> -DRM_MODE_ENCODER_DSI, NULL);
> + ret = drm_simple_encoder_init(drm, &dsi->encoder,
> + DRM_MODE_ENCODER_DSI);
> if (ret) {
> DRM_ERROR("Failed to encoder init to drm\n");
> return ret;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Laurent. On Sat, Mar 07, 2020 at 10:34:45PM +0200, Laurent Pinchart wrote: > Hi Sam, > > On Sat, Mar 07, 2020 at 09:08:13PM +0100, Sam Ravnborg wrote: > > On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote: > > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > > > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: > > > >> A call to drm_simple_encoder_init() initializes an encoder without > > > >> further functionality. It only provides the destroy callback to > > > >> cleanup the encoder's state. Only few drivers implement more > > > >> sophisticated encoders than that. Most drivers implement such a > > > >> simple encoder and can use drm_simple_encoder_init() instead. > > > >> > > > >> The patchset converts drivers where the encoder's instance is > > > >> embedded in a larger data structure. The driver releases the > > > >> memory during cleanup. Each patch replaces drm_encoder_init() with > > > >> drm_simple_encoder_init() and removes the (now unused) driver's > > > >> encoder functions. > > > >> > > > >> While the patchset is fairly large, the indiviual patches are self- > > > >> contained and can be merged independently from each other. The > > > >> simple-encoder functionality is currently in drm-misc-next, where > > > >> these patches could go as well. > > > > > > > > I've reviewed the whole series, including verifying that the few > > > > instances of struct drm_encoder_funcs that were not declared const were > > > > not modified somewhere to add more function pointers. > > > > > > > > Reviewed-by: Laurent Pinchart > > > > > > Thanks for the detailed review. > > > > > > > for all the patches. > > > > > > > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > > > > misnommer here. Several of the encoders in those drivers to implement > > > > additional functionality. They just expose them through > > > > drm_encoder_helper_funcs, not drm_encoder_funcs. > > > > > > True. It's called 'simple encoder' for the lack of a better name. It's > > > part of the simple KMS helpers, so the name's at least consistent. OTOH > > > I always find drm_simple_display_pipe a bad name. > > > > > > We can still rename the simple-encoder function without much effort. I'm > > > open for suggestions. > > > > IMO this does not belong in drm_simple_kms - but in drm_encoder. > > This only occurs to me after looking a bit more on the patches, > > you would have loved to get this feedback earlier. > > > > Most users do not need their owm drm_encoder_funcs definition, > > and would be happy with the default as provided by drm_simple_* > > > > As the cleanup is handled automatically when the drm device > > is teared down (in mode_config_rest()) I considered if we could here > > use the drmm_ namespace - but that felt wrong. > > > > My proposal is the following: > > - Move the implementation to drm_encoder.c > > - Name it drm_encoder_init_nofuncs() > > Or better, rename the existing drm_encoder_init() to > drm_encoder_init_funcs(), and rename drm_simple_encoder_init() to > drm_encoder_init() ? It's the common case. Agreed. It is a bit more involved which is the only reason I did not suggest it. But if we bite the bullet, then maybe do it properly. Cocinelle for the rescue... Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Sam, On Sat, Mar 07, 2020 at 09:08:13PM +0100, Sam Ravnborg wrote: > On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote: > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: > > >> A call to drm_simple_encoder_init() initializes an encoder without > > >> further functionality. It only provides the destroy callback to > > >> cleanup the encoder's state. Only few drivers implement more > > >> sophisticated encoders than that. Most drivers implement such a > > >> simple encoder and can use drm_simple_encoder_init() instead. > > >> > > >> The patchset converts drivers where the encoder's instance is > > >> embedded in a larger data structure. The driver releases the > > >> memory during cleanup. Each patch replaces drm_encoder_init() with > > >> drm_simple_encoder_init() and removes the (now unused) driver's > > >> encoder functions. > > >> > > >> While the patchset is fairly large, the indiviual patches are self- > > >> contained and can be merged independently from each other. The > > >> simple-encoder functionality is currently in drm-misc-next, where > > >> these patches could go as well. > > > > > > I've reviewed the whole series, including verifying that the few > > > instances of struct drm_encoder_funcs that were not declared const were > > > not modified somewhere to add more function pointers. > > > > > > Reviewed-by: Laurent Pinchart > > > > Thanks for the detailed review. > > > > > for all the patches. > > > > > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > > > misnommer here. Several of the encoders in those drivers to implement > > > additional functionality. They just expose them through > > > drm_encoder_helper_funcs, not drm_encoder_funcs. > > > > True. It's called 'simple encoder' for the lack of a better name. It's > > part of the simple KMS helpers, so the name's at least consistent. OTOH > > I always find drm_simple_display_pipe a bad name. > > > > We can still rename the simple-encoder function without much effort. I'm > > open for suggestions. > > IMO this does not belong in drm_simple_kms - but in drm_encoder. > This only occurs to me after looking a bit more on the patches, > you would have loved to get this feedback earlier. > > Most users do not need their owm drm_encoder_funcs definition, > and would be happy with the default as provided by drm_simple_* > > As the cleanup is handled automatically when the drm device > is teared down (in mode_config_rest()) I considered if we could here > use the drmm_ namespace - but that felt wrong. > > My proposal is the following: > - Move the implementation to drm_encoder.c > - Name it drm_encoder_init_nofuncs() Or better, rename the existing drm_encoder_init() to drm_encoder_init_funcs(), and rename drm_simple_encoder_init() to drm_encoder_init() ? It's the common case. > The patches posted in this thread would be a little simpler > as they would loose the added include file. > And the three drivers using the current infrastructure would need a > small update. > > I you decide to keep the current approach where the > functions are in drm_simple_* then the full series is: > Acked-by: Sam Ravnborg > > But I think moving it to drm_encoder.c would be the approach that would > make it simpler to understand/follow. So that get my (biased) vote. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Thomas. On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote: > Hi Laurent > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > > Hi Thomas, > > > > Thank you for the patch. > > > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: > >> A call to drm_simple_encoder_init() initializes an encoder without > >> further functionality. It only provides the destroy callback to > >> cleanup the encoder's state. Only few drivers implement more > >> sophisticated encoders than that. Most drivers implement such a > >> simple encoder and can use drm_simple_encoder_init() instead. > >> > >> The patchset converts drivers where the encoder's instance is > >> embedded in a larger data structure. The driver releases the > >> memory during cleanup. Each patch replaces drm_encoder_init() with > >> drm_simple_encoder_init() and removes the (now unused) driver's > >> encoder functions. > >> > >> While the patchset is fairly large, the indiviual patches are self- > >> contained and can be merged independently from each other. The > >> simple-encoder functionality is currently in drm-misc-next, where > >> these patches could go as well. > > > > I've reviewed the whole series, including verifying that the few > > instances of struct drm_encoder_funcs that were not declared const were > > not modified somewhere to add more function pointers. > > > > Reviewed-by: Laurent Pinchart > > Thanks for the detailed review. > > > > > for all the patches. > > > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > > misnommer here. Several of the encoders in those drivers to implement > > additional functionality. They just expose them through > > drm_encoder_helper_funcs, not drm_encoder_funcs. > > True. It's called 'simple encoder' for the lack of a better name. It's > part of the simple KMS helpers, so the name's at least consistent. OTOH > I always find drm_simple_display_pipe a bad name. > > We can still rename the simple-encoder function without much effort. I'm > open for suggestions. IMO this does not belong in drm_simple_kms - but in drm_encoder. This only occurs to me after looking a bit more on the patches, you would have loved to get this feedback earlier. Most users do not need their owm drm_encoder_funcs definition, and would be happy with the default as provided by drm_simple_* As the cleanup is handled automatically when the drm device is teared down (in mode_config_rest()) I considered if we could here use the drmm_ namespace - but that felt wrong. My proposal is the following: - Move the implementation to drm_encoder.c - Name it drm_encoder_init_nofuncs() The patches posted in this thread would be a little simpler as they would loose the added include file. And the three drivers using the current infrastructure would need a small update. I you decide to keep the current approach where the functions are in drm_simple_* then the full series is: Acked-by: Sam Ravnborg But I think moving it to drm_encoder.c would be the approach that would make it simpler to understand/follow. So that get my (biased) vote. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/panel: simple: Add support for Sharp LQ150X1LG11 panels"
Hi Peter. On Thu, Mar 05, 2020 at 01:07:07PM +, Peter Rosin wrote: > This reverts commit 0f9cdd743f7f8d470fff51b11250f02fc554cf1b. > > The interface of the panel is LVDS, not parallel. > The color depth is RGB888, not RGB565. > The panel has additional features, making it not so simple. > The only user (upstream) of this panel is appropriately using panel-lvds. > > Suggested-by: Thierry Reding > Suggested-by: Sam Ravnborg > Signed-off-by: Peter Rosin Thanks, applied to drm-misc-next and pushed out. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v4 4/6] drm/sprd: add Unisoc's drm display controller driver
Hi Kevin > > > + > > > +ifdef CONFIG_ARM64 > > > +KBUILD_CFLAGS += -mstrict-align > > > > > > There are many other drivers that do not use readl/writel for register > > access, > > yet none has this workaround... Even those that they are exclusively ARM64. > > > > Have you tried that it's not a buggy version of GCC? At the very least, I'd > > encourage you to add a brief comment about the problem + setup. > > > > ... In general I think one should follow the suggestions from Rob Herring. > > > Yocto v2.5 > aarch64-linaro-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011 > > Crash Stack: > /sprd/drv/dispc/dpu_r2p0.c:729 > 1796256 ff8008486650: f803c043sturx3, [x2,#60] > =>Unhandled fault: alignment fault (0x9661) at 0xff80098b883c > > 729 reg->mmu_min_ppn1 = 0; > 730 reg->mmu_ppn_range1 = 0x; > 731 reg->mmu_min_ppn2 = 0; > 732 reg->mmu_ppn_range2 = 0x; > > The above C code operation are continuous. The compiler may think that > the access can be completed by directly using two 64-bit assignment > operations, so it is optimized to 64-bit operation. What you see is a side-effect of using a sturct for register access. When you ave your code change to use readl()/writel() and friends this is no logner a problem, and you can drop the cc flag. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/22] drm/virtgpu: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: i386-randconfig-h002-20200307 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/virtio/virtgpu_display.c: In function 'vgdev_output_init':
>> drivers/gpu/drm/virtio/virtgpu_display.c:276:2: error: implicit declaration
>> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'?
>> [-Werror=implicit-function-declaration]
drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
^~~
drm_encoder_init
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 3 include/linux/slab.h:kmalloc_type
Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index
Cyclomatic Complexity 1 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 4 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
Cyclomatic Complexity 1
include/drm/drm_modeset_helper_vtables.h:drm_crtc_helper_add
Cyclomatic Complexity 1
include/drm/drm_modeset_helper_vtables.h:drm_encoder_helper_add
Cyclomatic Complexity 1
include/drm/drm_modeset_helper_vtables.h:drm_connector_helper_add
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_crtc_atomic_enable
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_crtc_atomic_check
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_crtc_atomic_flush
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_enc_mode_set
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_enc_enable
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_enc_disable
Cyclomatic Complexity 2
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_conn_detect
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:vgdev_atomic_commit_tail
Cyclomatic Complexity 67 include/asm-generic/getorder.h:get_order
Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
Cyclomatic Complexity 2
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_framebuffer_init
Cyclomatic Complexity 5
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_user_framebuffer_create
Cyclomatic Complexity 5
drivers/gpu/drm/virtio/virtgpu_display.c:vgdev_output_init
Cyclomatic Complexity 8
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_conn_mode_valid
Cyclomatic Complexity 4
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_conn_get_modes
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_conn_destroy
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_crtc_atomic_disable
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_crtc_mode_set_nofb
Cyclomatic Complexity 2
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_modeset_init
Cyclomatic Complexity 2
drivers/gpu/drm/virtio/virtgpu_display.c:virtio_gpu_modeset_fini
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:_GLOBAL__sub_I_00100_0_virtio_gpu_modeset_init
Cyclomatic Complexity 1
drivers/gpu/drm/virtio/virtgpu_display.c:_GLOBAL__sub_D_00100_1_virtio_gpu_modeset_init
cc1: some warnings being treated as errors
vim +276 drivers/gpu/drm/virtio/virtgpu_display.c
243
244 static int vgdev_output_init(struct virtio_gpu_device *vgdev, int index)
245 {
246 struct drm_device *dev = vgdev->ddev;
247 struct virtio_gpu_output *output = vgdev->outputs + index;
248 struct drm_connector *connector = &output->conn;
249 struct drm_encoder *encoder = &output->enc;
250 struct drm_crtc *crtc = &output->crtc;
251 struct drm_plane *primary, *cursor;
252
253 output->index = index;
254 if (index == 0) {
255
Re: [PATCH 07/22] drm/i2c/tda998x: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: x86_64-randconfig-h002-20200307 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_encoder_init':
>> drivers/gpu/drm/i2c/tda998x_drv.c:2018:8: error: implicit declaration of
>> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'?
>> [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(drm, &priv->encoder,
^~~
drm_encoder_init
cc1: some warnings being treated as errors
vim +2018 drivers/gpu/drm/i2c/tda998x_drv.c
2000
2001 static int tda998x_encoder_init(struct device *dev, struct drm_device
*drm)
2002 {
2003 struct tda998x_priv *priv = dev_get_drvdata(dev);
2004 u32 crtcs = 0;
2005 int ret;
2006
2007 if (dev->of_node)
2008 crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
2009
2010 /* If no CRTCs were found, fall back to our old behaviour */
2011 if (crtcs == 0) {
2012 dev_warn(dev, "Falling back to first CRTC\n");
2013 crtcs = 1 << 0;
2014 }
2015
2016 priv->encoder.possible_crtcs = crtcs;
2017
> 2018 ret = drm_simple_encoder_init(drm, &priv->encoder,
2019DRM_MODE_ENCODER_TMDS);
2020 if (ret)
2021 goto err_encoder;
2022
2023 ret = drm_bridge_attach(&priv->encoder, &priv->bridge, NULL, 0);
2024 if (ret)
2025 goto err_bridge;
2026
2027 return 0;
2028
2029 err_bridge:
2030 drm_encoder_cleanup(&priv->encoder);
2031 err_encoder:
2032 return ret;
2033 }
2034
---
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 RFC v4 4/6] drm/sprd: add Unisoc's drm display controller driver
Hi Emil,
Maybe here is your missing comments
I ’m really sorry, sometimes I forget to use plain text by gmail,
never make the same mistake again.
Emil Velikov 于2020年3月3日周二 上午2:29写道：
>
> Hi Kevin,
>
> There's a few small suggestions, although overall the driver looks a lot
> better.
>
> On Thu, 27 Feb 2020 at 08:14, Kevin Tang wrote:
>
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/dpu/Makefile
> > @@ -0,0 +1,7 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +ifdef CONFIG_ARM64
> > +KBUILD_CFLAGS += -mstrict-align
>
>
> There are many other drivers that do not use readl/writel for register access,
> yet none has this workaround... Even those that they are exclusively ARM64.
>
> Have you tried that it's not a buggy version of GCC? At the very least, I'd
> encourage you to add a brief comment about the problem + setup.
>
> ... In general I think one should follow the suggestions from Rob Herring.
>
Yocto v2.5
aarch64-linaro-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
Crash Stack:
/sprd/drv/dispc/dpu_r2p0.c:729
1796256 ff8008486650: f803c043sturx3, [x2,#60]
=>Unhandled fault: alignment fault (0x9661) at 0xff80098b883c
729 reg->mmu_min_ppn1 = 0;
730 reg->mmu_ppn_range1 = 0x;
731 reg->mmu_min_ppn2 = 0;
732 reg->mmu_ppn_range2 = 0x;
The above C code operation are continuous. The compiler may think that
the access can be completed by directly using two 64-bit assignment
operations, so it is optimized to 64-bit operation.
Assembly code：
=
/sprd/drv/dispc/dpu_r2p0.c:729
1796244 ff8008486638: 91200022add x2, x1, #0x800
/sprd/drv/dispc/dpu_r2p0.c:728
1796246 ff800848663c: b908003fstr wzr, [x1,#2048]
/sprd/drv/dispc/dpu_r2p0.c:729
1796248 ff8008486640: d2dfffe3mov x3,
#0x
/sprd/drv/dispc/dpu_r2p0.c:733
1796250 ff8008486644: 12bfffc4mov w4, #0x1
/sprd/drv/dispc/dpu_r2p0.c:735
1796252 ff8008486648: 529fffe5mov w5, #0x
/sprd/drv/dispc/dpu_r2p0.c:741
1796254 ff800848664c: 5280mov w0, #0x0
/sprd/drv/dispc/dpu_r2p0.c:729
1796256 ff8008486650: f803c043sturx3, [x2,#60]
=>Unhandled fault: alignment fault (0x9661) at 0xff80098b883c
/sprd/drv/dispc/dpu_r2p0.c:730
1796258 ff8008486654: f8044043sturx3, [x2,#68]
/sprd/drv/dispc/dpu_r2p0.c:735
1796260 ff8008486658: b901e425str w5, [x1,#484]
/sprd/drv/dispc/dpu_r2p0.c:733
1796262 ff800848665c: b9080c24str w4, [x1,#2060]
1796263 ff8008486660: f9400274ldr x20, [x19]
>
>
> > +static void dpu_dump(struct dpu_context *ctx)
> > +{
> > + u32 *reg = (u32 *)ctx->base;
> > + int i;
> > +
> > + pr_info(" 0 4 8 C\n");
> > + for (i = 0; i < 256; i += 4) {
> > + pr_info("%04x: 0x%08x 0x%08x 0x%08x 0x%08x\n",
> > + i * 4, reg[i], reg[i + 1], reg[i + 2], reg[i + 3]);
>
> Using some of the helpers from drm_print.h would be better than pr_*.
> This applies for the rest of the patch.
>
>
> > +static void dpu_clean_all(struct dpu_context *ctx)
> > +{
> > + int i;
> > + struct dpu_reg *reg = (struct dpu_reg *)ctx->base;
> > +
> > + for (i = 0; i < 8; i++)
>
> This "< 8" seem pretty magical. How about "< ARRAY_SIZE(reg->layers)"
> Same logic applies through the rest of the patch.
>
>
> > +static int dpu_wait_stop_done(struct dpu_context *ctx)
> > +{
> > + int rc;
> > +
> > + if (ctx->stopped)
> > + return 0;
> > +
> The stopped handling does look suspicious. Admittedly I did not look too
> closely
> at the dpu_flip code, which seems to require it.
>
> Let's add a small comment in the struct dpu_context::stopped declaration, why
> it
> is needed, if it truely is.
>
> > + rc = wait_event_interruptible_timeout(ctx->wait_queue,
> > ctx->evt_stop,
> > + msecs_to_jiffies(500));
> > + ctx->evt_stop = false;
> > +
> > + ctx->stopped = true;
> > +
> > + if (!rc) {
> > + pr_err("dpu wait for stop done time out!\n");
> > + return -ETIMEDOUT;
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> > +static void dpu_stop(struct dpu_context *ctx)
> > +{
> > + struct dpu_reg *reg = (struct dpu_reg *)ctx->base;
> > +
> > + if (ctx->stopped)
> > + return;
> > +
> > + if (ctx->if_type == SPRD_DISPC_IF_DPI)
> > + reg->dpu_ctrl |= BIT(1);
> > +
> > + dpu_wait_stop_done(ctx);
> > +
> > + pr_info("dpu stop\n");
>
> This and the dpu_run pr_info() messages can be removed.
>
>
> > +}
> > +
> > +static void dpu_run(struct dpu_context *ctx)
> > +{
> > + struct dpu_reg *reg = (struct dpu_reg *)ctx->base;
> > +
> > + if (!ctx->stopped)
> > +
Re: [PATCH RFC v4 4/6] drm/sprd: add Unisoc's drm display controller driver
Emil Velikov 于2020年3月7日周六 上午1:14写道：
>
> On Thu, 5 Mar 2020 at 13:15, tang pengchuan wrote:
> > On Tue, Mar 3, 2020 at 2:29 AM Emil Velikov
> > wrote:
>
> >> Have you seen a case where the 0 or default case are reached? AFAICT they
> >> will
> >> never trigger. So one might as well use:
> >>
> >> switch (angle) {
> >> case DRM_MODE_FOO:
> >> return DPU_LAYER_ROTATION_FOO;
> >> ...
> >> case DRM_MODE_BAR:
> >> return DPU_LAYER_ROTATION_BAR;
> >> }
> >>
> > Yeah, the 0 maybe unused code, i will remove it.
> > But i think default is need, because userspace could give an incorrect
> > value .
> > So we need to setup a default value and doing error check.
>
> As mentioned in the documentation [0] input (userspace) validation
> should happen in atomic_check. This function here is called during
> atomic_flush which is _not_ allowed to fail.
In drm atomic commit codepath:
drm_atomic_commit-->drm_atomic_plane_check--->drm_plane_check_pixel_format
already helped us check DRM_FORMAT_XXX, so default laber is dead code.
Is just a waste of time and increases the complexity of the code for no reason.
We can't use "return" replace "break"
Because "switch(format)" and "switch(blending)"exist at the same
funtion, and I don't think it's a good idea to split them.
I think there are two solutions：
1. Remove default label completely
2. Add "default: // Do nothing", Eg:
int flag = value > 1000 ? 1 : 0;
swich(flag) {
case 0:
// do something
break;
case 1:
// do something
break;
default: // do nothing
break;
}
>
>
>
> >> The default case here should be unreachable. Either it is or the upper
> >> layer (or
> >> earlier code) should ensure that.
> >
> > There will be some differences in the formats supported by different chips,
> > but userspace will only have one set of code.
> > So it is necessary to check whether the parameters passed by the user layer
> > are wrong. I think it is necessary
>
> As said above - this type of issues should be checked _before_
> reaching atomic_flush - aka in atomic_check.
Your are right, switch(format) and switch(blending) will never reach
default label, so it's dead code.
As for rotation, we will ensure it is correct at the user layer.
>
>
> >> > +static struct drm_plane *sprd_plane_init(struct drm_device *drm,
> >> > + struct sprd_dpu *dpu)
> >> > +{
> >> > + struct drm_plane *primary = NULL;
> >> > + struct sprd_plane *p = NULL;
> >> > + struct dpu_capability cap = {};
> >> > + int err, i;
> >> > +
> >> > + if (dpu->core && dpu->core->capability)
> >> As mentioned before - this always evaluates to true, so drop the check.
> >> Same applies for the other dpu->core->foo checks.
> >>
> >> Still not a huge fan of the abstraction layer, but I guess you're hesitant
> >> on
> >> removing it.
> >
> > Sometimes, some "dpu->core->foo" maybe always need, compatibility will be
> > better.
> > eg:
> >
> > if (dpu->glb && dpu->glb->power)
> > dpu->glb->power(ctx, true);
> > if (dpu->glb && dpu->glb->enable)
> > dpu->glb->enable(ctx);
> >
> > if (ctx->is_stopped && dpu->glb && dpu->glb->reset)
> > dpu->glb->reset(ctx);
> >
> > if (dpu->clk && dpu->clk->init)
> > dpu->clk->init(ctx);
> > if (dpu->clk && dpu->clk->enable)
> > dpu->clk->enable(ctx);
> >
> > if (dpu->core && dpu->core->init)
> > dpu->core->init(ctx);
> > if (dpu->core && dpu->core->ifconfig)
> > dpu->core->ifconfig(ctx);
> >
>
> If there are no hooks, then the whole thing is dead code. As such it
> should not be included.
>
>
> > >
> > > Note: Custom properties should be separate patches. This includes
> > > documentation
> > > why they are needed and references to open-source userspace.
> > This only need for our chips, what documentation do we need to provide?
> >
>
> KMS properties should be generic. Reason being is that divergence
> causes substantial overhead, and fragility, to each and every
> userspace consumer. The documentation has some general notes on the
> topic [1]. Don't forget the "Testing and validation" section ;-)
>
> Although I've tried to catch everything, I might have missed a comment
> or two due the HTML formatting. Please toggle to plain text [2] for
> the future.
I got it
>
> Thanks
> -Emil
>
> [0] https://www.kernel.org/doc/html/v5.5/gpu/drm-kms.html
> [1] Documentation/gpu/drm-uapi.rst in particular "Open-Source
> Userspace Requirements"
> [2] https://smallbusiness.chron.com/reply-inline-gmail-40679.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2] dma-buf: heaps: bugfix for selftest failure
From: Leon He
There are two errors in the dmabuf-heap selftest:
1. The 'char name[5]' was not initialized to zero, which will cause
strcmp(name, "vgem") failed in check_vgem().
2. The return value of test_alloc_errors() should be reversed, other-
wise the while loop in main() will be broken.
Signed-off-by: Leon He
---
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
index cd5e1f6..836b185 100644
--- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -22,7 +22,7 @@
static int check_vgem(int fd)
{
drm_version_t version = { 0 };
- char name[5];
+ char name[5] = { 0 };
int ret;
version.name_len = 4;
@@ -357,7 +357,7 @@ static int test_alloc_errors(char *heap_name)
if (heap_fd >= 0)
close(heap_fd);
- return ret;
+ return !ret;
}
int main(void)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: use-after-free Read in dmabuffs_dname
On Fri, 06 Mar 2020 21:41:13 -0800 > syzbot found the following crash on: > > HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=11653ac3e0 > kernel config: https://syzkaller.appspot.com/x/.config?x=9833e26bab355358 > dashboard link: https://syzkaller.appspot.com/bug?extid=3643a18836bce555bff6 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > userspace arch: i386 > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com > > == > BUG: KASAN: use-after-free in dmabuffs_dname+0x4f4/0x560 > drivers/dma-buf/dma-buf.c:48 > Read of size 8 at addr 8880a6b390e8 by task syz-executor.1/2394 > > CPU: 1 PID: 2394 Comm: syz-executor.1 Not tainted 5.6.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x197/0x210 lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 > __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506 > kasan_report+0x12/0x20 mm/kasan/common.c:641 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 > dmabuffs_dname+0x4f4/0x560 drivers/dma-buf/dma-buf.c:48 > tomoyo_realpath_from_path+0x165/0x660 security/tomoyo/realpath.c:259 > tomoyo_get_realpath security/tomoyo/file.c:151 [inline] > tomoyo_check_open_permission+0x2a3/0x3e0 security/tomoyo/file.c:771 > tomoyo_file_open security/tomoyo/tomoyo.c:319 [inline] > tomoyo_file_open+0xa9/0xd0 security/tomoyo/tomoyo.c:314 > security_file_open+0x71/0x300 security/security.c:1529 > do_dentry_open+0x37a/0x1380 fs/open.c:784 > vfs_open+0xa0/0xd0 fs/open.c:914 > do_last fs/namei.c:3490 [inline] > path_openat+0x12ee/0x3490 fs/namei.c:3607 > do_filp_open+0x192/0x260 fs/namei.c:3637 > do_sys_openat2+0x5eb/0x7e0 fs/open.c:1149 > do_sys_open+0xf2/0x180 fs/open.c:1165 > __do_compat_sys_open fs/open.c:1212 [inline] > __se_compat_sys_open fs/open.c:1210 [inline] > __ia32_compat_sys_open+0x79/0xb0 fs/open.c:1210 > do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] > do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > RIP: 0023:0xf7fd8e39 > Code: 1d 00 00 00 89 d3 5b 5e 5d c3 8b 04 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 90 > 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 > 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > RSP: 002b:f5db2014 EFLAGS: 0296 ORIG_RAX: 0005 > RAX: ffda RBX: f5db204c RCX: > RDX: RSI: 0c09 RDI: f5db204c > RBP: f5db2168 R08: R09: > R10: R11: R12: > R13: R14: R15: > > Allocated by task 2388: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > __kasan_kmalloc mm/kasan/common.c:515 [inline] > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:488 > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 > __do_kmalloc mm/slab.c:3656 [inline] > __kmalloc+0x163/0x770 mm/slab.c:3665 > kmalloc include/linux/slab.h:560 [inline] > kzalloc include/linux/slab.h:669 [inline] > dma_buf_export+0x24d/0xa80 drivers/dma-buf/dma-buf.c:533 > ion_alloc drivers/staging/android/ion/ion.c:386 [inline] > ion_ioctl+0x5a9/0xd20 drivers/staging/android/ion/ion.c:495 > compat_ptr_ioctl+0x6e/0xa0 fs/ioctl.c:804 > __do_compat_sys_ioctl fs/ioctl.c:857 [inline] > __se_compat_sys_ioctl fs/ioctl.c:808 [inline] > __ia32_compat_sys_ioctl+0x245/0x2c0 fs/ioctl.c:808 > do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] > do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > > Freed by task 2380: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > kasan_set_free_info mm/kasan/common.c:337 [inline] > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:476 > kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 > __cache_free mm/slab.c:3426 [inline] > kfree+0x10a/0x2c0 mm/slab.c:3757 > dma_buf_release+0x343/0x420 drivers/dma-buf/dma-buf.c:111 > __fput+0x2ff/0x890 fs/file_table.c:280 > fput+0x16/0x20 fs/file_table.c:313 > task_work_run+0x145/0x1c0 kernel/task_work.c:113 > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:164 > prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline] > syscall_return_slowpath arch/x86/entr
Re: [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala wrote: > From: Ville Syrjälä > > The currently listed dotclocks disagree with the currently > listed vrefresh rates. Change the dotclocks to match the vrefresh. > > Someone tell me which (if either) of the dotclock or vreresh is > correct? > > Cc: Linus Walleij > Cc: Sam Ravnborg > Signed-off-by: Ville Syrjälä These are better than what is currently in the driver at least, we don't know the real dotclocks. (No datasheet.) Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks
Hi Ville!
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Linus Walleij
> Cc: Thierry Reding
> Signed-off-by: Ville Syrjälä
This display is particularly peculiar since it uses
the ITU-T packed streams and like DSI those have
a different clocking than whatever is clocked out to the
actual display by the pixel clock.
Datasheet is here:
https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf
I see I have consistently set the clocks two orders of
magnitude wrong in this driver, mea culpa :P
But I checked them all and what I think you should
do is just divide them all by 100 and leave as-is.
> /* Serial RGB modes */
> static const struct drm_display_mode srgb_320x240_mode = {
> - .clock = 2453500,
> + .clock = 14478,
Please set to 24535.
> static const struct drm_display_mode srgb_360x240_mode = {
> - .clock = 270,
> + .clock = 10014,
Please set to 27000.
> /* This is the only mode listed for parallel RGB in the datasheet */
> static const struct drm_display_mode prgb_320x240_mode = {
> - .clock = 640,
> + .clock = 6429,
Please set to 64000.
> static const struct drm_display_mode yuv_640x320_mode = {
> - .clock = 2454000,
> + .clock = 18954,
Please set to 24540.
> static const struct drm_display_mode yuv_720x360_mode = {
> - .clock = 270,
> + .clock = 22911,
Please set to 27000.
> /* BT.656 VGA mode, 640x480 */
> static const struct drm_display_mode itu_r_bt_656_640_mode = {
> - .clock = 2454000,
> + .clock = 27480,
Please set to 24540.
> /* BT.656 D1 mode 720x480 */
> static const struct drm_display_mode itu_r_bt_656_720_mode = {
> - .clock = 270,
> + .clock = 29880,
Please set to 27000.
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock
Hi Ville,
On Mon, Mar 2, 2020 at 9:34 PM Ville Syrjala
wrote:
> .mode = {
> /* The internal pixel clock of the NT35510 is 20 MHz */
> - .clock = 2000,
> + .clock = 23581,
I double checked this with the datasheet NT35510 Application Note V0.07 HYDIS
and all documentation is in line with the comment: the internal clock
frequency of
the dotclock is 20 MHz so this should be set to 2 (kHz) sorry for putting
the three orders of magnitude too big number there :P
This clock isn't used by any drivers because this is a command mode DSI
panel with a DSI link clocked from the host. (hs_rate or lp_rate).
The internal formula shows how the actual vrefresh can be calculated for
the display in respone to setting of the internal registers, see page 34:
https://dflund.se/~triad/NT35510-appnote.pdf
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/22] drm/vkms: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: i386-randconfig-h001-20200307 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu//drm/vkms/vkms_output.c: In function 'vkms_output_init':
>> drivers/gpu//drm/vkms/vkms_output.c:70:8: error: implicit declaration of
>> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'?
>> [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
^~~
drm_encoder_init
cc1: some warnings being treated as errors
vim +70 drivers/gpu//drm/vkms/vkms_output.c
34
35 int vkms_output_init(struct vkms_device *vkmsdev, int index)
36 {
37 struct vkms_output *output = &vkmsdev->output;
38 struct drm_device *dev = &vkmsdev->drm;
39 struct drm_connector *connector = &output->connector;
40 struct drm_encoder *encoder = &output->encoder;
41 struct drm_crtc *crtc = &output->crtc;
42 struct drm_plane *primary, *cursor = NULL;
43 int ret;
44
45 primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY,
index);
46 if (IS_ERR(primary))
47 return PTR_ERR(primary);
48
49 if (enable_cursor) {
50 cursor = vkms_plane_init(vkmsdev,
DRM_PLANE_TYPE_CURSOR, index);
51 if (IS_ERR(cursor)) {
52 ret = PTR_ERR(cursor);
53 goto err_cursor;
54 }
55 }
56
57 ret = vkms_crtc_init(dev, crtc, primary, cursor);
58 if (ret)
59 goto err_crtc;
60
61 ret = drm_connector_init(dev, connector, &vkms_connector_funcs,
62 DRM_MODE_CONNECTOR_VIRTUAL);
63 if (ret) {
64 DRM_ERROR("Failed to init connector\n");
65 goto err_connector;
66 }
67
68 drm_connector_helper_add(connector, &vkms_conn_helper_funcs);
69
> 70 ret = drm_simple_encoder_init(dev, encoder,
DRM_MODE_ENCODER_VIRTUAL);
---
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
[PATCH] drm/lima: add trace point for tasks
track lima task start which can be combined with
dma_fence_signal to identify task execution time.
example command to record:
trace-cmd record -i \
-e "lima:lima_task_submit" -e "lima:lima_task_run" \
-e "*fence:*fence_signaled" -e "drm:drm_vblank_event" \
-e "drm:drm_vblank_event_queued" sleep 4
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/Makefile | 3 +-
drivers/gpu/drm/lima/lima_sched.c | 5 +++-
drivers/gpu/drm/lima/lima_sched.h | 1 +
drivers/gpu/drm/lima/lima_trace.c | 7 +
drivers/gpu/drm/lima/lima_trace.h | 50 +++
5 files changed, 64 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/lima/lima_trace.c
create mode 100644 drivers/gpu/drm/lima/lima_trace.h
diff --git a/drivers/gpu/drm/lima/Makefile b/drivers/gpu/drm/lima/Makefile
index a85444b0a1d4..6e7b788408e8 100644
--- a/drivers/gpu/drm/lima/Makefile
+++ b/drivers/gpu/drm/lima/Makefile
@@ -14,6 +14,7 @@ lima-y := \
lima_sched.o \
lima_ctx.o \
lima_dlbu.o \
- lima_bcast.o
+ lima_bcast.o \
+ lima_trace.o
obj-$(CONFIG_DRM_LIMA) += lima.o
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index f295479e3733..98d0d410b7d7 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -3,7 +3,6 @@
#include
#include
-#include
#include
#include "lima_drv.h"
@@ -12,6 +11,7 @@
#include "lima_mmu.h"
#include "lima_l2_cache.h"
#include "lima_gem.h"
+#include "lima_trace.h"
struct lima_fence {
struct dma_fence base;
@@ -177,6 +177,7 @@ struct dma_fence *lima_sched_context_queue_task(struct
lima_sched_context *conte
{
struct dma_fence *fence = dma_fence_get(&task->base.s_fence->finished);
+ trace_lima_task_submit(task);
drm_sched_entity_push_job(&task->base, &context->base);
return fence;
}
@@ -251,6 +252,8 @@ static struct dma_fence *lima_sched_run_job(struct
drm_sched_job *job)
if (last_vm)
lima_vm_put(last_vm);
+ trace_lima_task_run(task);
+
pipe->error = false;
pipe->task_run(pipe, task);
diff --git a/drivers/gpu/drm/lima/lima_sched.h
b/drivers/gpu/drm/lima/lima_sched.h
index e29f5e3b675b..e5db1919f446 100644
--- a/drivers/gpu/drm/lima/lima_sched.h
+++ b/drivers/gpu/drm/lima/lima_sched.h
@@ -6,6 +6,7 @@
#include
#include
+#include
struct lima_vm;
diff --git a/drivers/gpu/drm/lima/lima_trace.c
b/drivers/gpu/drm/lima/lima_trace.c
new file mode 100644
index ..ea1c7289bebc
--- /dev/null
+++ b/drivers/gpu/drm/lima/lima_trace.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/* Copyright 2020 Qiang Yu */
+
+#include "lima_sched.h"
+
+#define CREATE_TRACE_POINTS
+#include "lima_trace.h"
diff --git a/drivers/gpu/drm/lima/lima_trace.h
b/drivers/gpu/drm/lima/lima_trace.h
new file mode 100644
index ..9308b948b69d
--- /dev/null
+++ b/drivers/gpu/drm/lima/lima_trace.h
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/* Copyright 2020 Qiang Yu */
+
+#if !defined(_LIMA_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _LIMA_TRACE_H_
+
+#include
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM lima
+#define TRACE_INCLUDE_FILE lima_trace
+
+DECLARE_EVENT_CLASS(lima_task,
+ TP_PROTO(struct lima_sched_task *task),
+ TP_ARGS(task),
+ TP_STRUCT__entry(
+ __field(uint64_t, task_id)
+ __field(unsigned int, context)
+ __field(unsigned int, seqno)
+ __string(pipe, task->base.sched->name)
+ ),
+
+ TP_fast_assign(
+ __entry->task_id = task->base.id;
+ __entry->context = task->base.s_fence->finished.context;
+ __entry->seqno = task->base.s_fence->finished.seqno;
+ __assign_str(pipe, task->base.sched->name)
+ ),
+
+ TP_printk("task=%llu, context=%u seqno=%u pipe=%s",
+ __entry->task_id, __entry->context, __entry->seqno,
+ __get_str(pipe))
+);
+
+DEFINE_EVENT(lima_task, lima_task_submit,
+TP_PROTO(struct lima_sched_task *task),
+TP_ARGS(task)
+);
+
+DEFINE_EVENT(lima_task, lima_task_run,
+TP_PROTO(struct lima_sched_task *task),
+TP_ARGS(task)
+);
+
+#endif
+
+/* This part must be outside protection */
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/lima
+#include
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/lima: save task info dump when task fail
Save all information to start a task which can be exported to user
for debug usage. Dump file data format is specified in lima_dump.h
v2:
Add include header to address build robot complain.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.c | 13 +++
drivers/gpu/drm/lima/lima_device.h | 8 ++
drivers/gpu/drm/lima/lima_dump.h | 77 +
drivers/gpu/drm/lima/lima_sched.c | 129 +
drivers/gpu/drm/lima/lima_sched.h | 7 ++
5 files changed, 234 insertions(+)
create mode 100644 drivers/gpu/drm/lima/lima_dump.h
diff --git a/drivers/gpu/drm/lima/lima_device.c
b/drivers/gpu/drm/lima/lima_device.c
index 19829b543024..42a00171fea5 100644
--- a/drivers/gpu/drm/lima/lima_device.c
+++ b/drivers/gpu/drm/lima/lima_device.c
@@ -344,6 +344,12 @@ int lima_device_init(struct lima_device *ldev)
if (err)
goto err_out5;
+ ldev->dump.magic = LIMA_DUMP_MAGIC;
+ ldev->dump.version_major = LIMA_DUMP_MAJOR;
+ ldev->dump.version_minor = LIMA_DUMP_MINOR;
+ INIT_LIST_HEAD(&ldev->error_task_list);
+ mutex_init(&ldev->error_task_list_lock);
+
dev_info(ldev->dev, "bus rate = %lu\n", clk_get_rate(ldev->clk_bus));
dev_info(ldev->dev, "mod rate = %lu", clk_get_rate(ldev->clk_gpu));
@@ -370,6 +376,13 @@ int lima_device_init(struct lima_device *ldev)
void lima_device_fini(struct lima_device *ldev)
{
int i;
+ struct lima_sched_error_task *et, *tmp;
+
+ list_for_each_entry_safe(et, tmp, &ldev->error_task_list, list) {
+ list_del(&et->list);
+ kvfree(et);
+ }
+ mutex_destroy(&ldev->error_task_list_lock);
lima_fini_pp_pipe(ldev);
lima_fini_gp_pipe(ldev);
diff --git a/drivers/gpu/drm/lima/lima_device.h
b/drivers/gpu/drm/lima/lima_device.h
index 31158d86271c..f17173f47f26 100644
--- a/drivers/gpu/drm/lima/lima_device.h
+++ b/drivers/gpu/drm/lima/lima_device.h
@@ -6,8 +6,11 @@
#include
#include
+#include
+#include
#include "lima_sched.h"
+#include "lima_dump.h"
enum lima_gpu_id {
lima_gpu_mali400 = 0,
@@ -94,6 +97,11 @@ struct lima_device {
u32 *dlbu_cpu;
dma_addr_t dlbu_dma;
+
+ /* debug info */
+ struct lima_dump_head dump;
+ struct list_head error_task_list;
+ struct mutex error_task_list_lock;
};
static inline struct lima_device *
diff --git a/drivers/gpu/drm/lima/lima_dump.h b/drivers/gpu/drm/lima/lima_dump.h
new file mode 100644
index ..ca243d99c51b
--- /dev/null
+++ b/drivers/gpu/drm/lima/lima_dump.h
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2020 Qiang Yu */
+
+#ifndef __LIMA_DUMP_H__
+#define __LIMA_DUMP_H__
+
+#include
+
+/**
+ * dump file format for all the information to start a lima task
+ *
+ * top level format
+ * | magic code "LIMA" | format version | num tasks | data size |
+ * | reserved | reserved | reserved | reserved |
+ * | task 1 ID | task 1 size | num chunks | reserved | task 1 data |
+ * | task 2 ID | task 2 size | num chunks | reserved | task 2 data |
+ * ...
+ *
+ * task data format
+ * | chunk 1 ID | chunk 1 size | reserved | reserved | chunk 1 data |
+ * | chunk 2 ID | chunk 2 size | reserved | reserved | chunk 2 data |
+ * ...
+ *
+ */
+
+#define LIMA_DUMP_MAJOR 1
+#define LIMA_DUMP_MINOR 0
+
+#define LIMA_DUMP_MAGIC 0x414d494c
+
+struct lima_dump_head {
+ __u32 magic;
+ __u16 version_major;
+ __u16 version_minor;
+ __u32 num_tasks;
+ __u32 size;
+ __u32 reserved[4];
+};
+
+#define LIMA_DUMP_TASK_GP 0
+#define LIMA_DUMP_TASK_PP 1
+#define LIMA_DUMP_TASK_NUM 2
+
+struct lima_dump_task {
+ __u32 id;
+ __u32 size;
+ __u32 num_chunks;
+ __u32 reserved;
+};
+
+#define LIMA_DUMP_CHUNK_FRAME 0
+#define LIMA_DUMP_CHUNK_BUFFER1
+#define LIMA_DUMP_CHUNK_PROCESS_NAME 2
+#define LIMA_DUMP_CHUNK_PROCESS_ID3
+#define LIMA_DUMP_CHUNK_NUM 4
+
+struct lima_dump_chunk {
+ __u32 id;
+ __u32 size;
+ __u32 reserved[2];
+};
+
+struct lima_dump_chunk_buffer {
+ __u32 id;
+ __u32 size;
+ __u32 va;
+ __u32 reserved;
+};
+
+struct lima_dump_chunk_pid {
+ __u32 id;
+ __u32 size;
+ __u32 pid;
+ __u32 reserved;
+};
+
+#endif
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 3886999b4533..f295479e3733 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include "lima_drv.h"
#include "lima_sched.h"
@@ -256,6 +257,132 @@ static struct dma_fence *lima_sched_run_job(struct
drm_sched_job *job)
return task->fence;
}
+static void lima_sched_build_error_task_list(struct lima_sched_task *task)
+{
+ struct lima_sched_error_task *et;
+ struct lima_sched_pipe *pipe = to_lima_pipe(task->base.sched);
+ st
Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up
Hi Lyude,
On 3/7/20 12:54 AM, Lyude Paul wrote:
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
Hi,
On 2/26/20 5:05 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede
wrote:
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede
wrote:
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot of
work on DP MST, but if this rings a bell to anyone else feel
free to weigh in on this.
Might be a duplicate of:
https://gitlab.freedesktop.org/drm/amd/issues/1052
Looks like you are right, reverting the commit which the bisect
from that issue points to:
cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic
check")
Fixes the issue for me. I will add a comment to the issue.
Note I'm using integrated Intel gfx, so that means that this issue
definitely is not amdgpu specific.
I'm not too familiar with the mst code, but I wonder if we were
exceeding the bandwidth limits in some setups and it just happened to
work, but now that we enforcing them, they don't which is correct, but
a regression from some users' perspective?
I seriously doubt that is the case according to:
https://support.lenovo.com/nl/en/solutions/pd029622
The gen 2 tb3 dock can handle 2 external
displays at 3840*2160@60Hz together with the internal
panel being on and both my external displays run at
1920x1080@60 so I'm consuming less then half of the
maximum bandwidth.
OK-so I wasn't actually able to reproduce this issue with my setup (I've got a
X1 Carbon 7th generation, but I don't have the 2nd generation dock - only the
first generation dock) but I'm certain I've actually fixed it now, since I
realized we did not have a very good understanding of how PBN limitations are
advertised with MST. I rewrote the bandwidth checks again, and in the process
also found a much more subtle regression that got introduced in 5.6, which
would sometimes cause MST probing to appear to just stop in it's tracks with
no messages.
I cc'd both patch series to you, so I'd recommend applying them both onto your
kernel and seeing if that fixes your issues. If it still doesn't, then get me
some kernel logs with:
drm.debug=0x116 log_buf_len=50M
And I'll take a closer look. I'm pretty confident this should fix everything
though :)
I can confirm that the v2 series you posted fixes the problem of only of the 2
FHD monitors on my Lenovo TB3 gen 2 dock lighting up, thank you!
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/dp_mst: Fix bandwidth checking regressions from DSC patches
Hi, On 3/7/20 12:46 AM, Lyude Paul wrote: AMD's patch series for adding DSC support to the MST helpers unfortunately introduced a few regressions into the kernel that I didn't get around to fixing until just now. I would have reverted the changes earlier, but seeing as that would have reverted all of amd's DSC support + everything that was done on top of that I really wanted to avoid doing that. Anyway, this should fix everything bandwidth-check related as far as I can tell (I found some other regressions unrelated to AMD's DSC patches which I'll be sending out patches for shortly). Note that I don't have any DSC displays locally yet, so if someone from AMD could sanity check this I would appreciate it ♥. I can confirm that this series fixes only of the 2 FHD monitors on my Lenovo TB3 gen 2 dock lighting up, thank you! This series is: Tested-by: Hans de Goede Regards, Hans Cc: Mikita Lipski Cc: Alex Deucher Cc: Sean Paul Cc: Hans de Goede Lyude Paul (4): drm/dp_mst: Rename drm_dp_mst_is_dp_mst_end_device() to be less redundant drm/dp_mst: Use full_pbn instead of available_pbn for bandwidth checks drm/dp_mst: Reprobe path resources in CSN handler drm/dp_mst: Rewrite and fix bandwidth limit checks drivers/gpu/drm/drm_dp_mst_topology.c | 185 ++ include/drm/drm_dp_mst_helper.h | 4 +- 2 files changed, 129 insertions(+), 60 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/vboxvideo/vboxvideo.h: Replace zero-length array with flexible-array member
Hi,
On 3/6/20 11:41 AM, Daniel Vetter wrote:
On Thu, Mar 05, 2020 at 03:22:38PM +0100, Hans de Goede wrote:
Hi,
On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
Patch looks good to me:
Reviewed-by: Hans de Goede
You're also going to push this? r-b by maintainers without any hint to
what's going to happen is always rather confusing.
I've pushed this now, sorry for the confusion I will be more
clear about my intentions next time.
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/vboxvideo.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vboxvideo/vboxvideo.h
b/drivers/gpu/drm/vboxvideo/vboxvideo.h
index 0592004f71aa..a5de40fe1a76 100644
--- a/drivers/gpu/drm/vboxvideo/vboxvideo.h
+++ b/drivers/gpu/drm/vboxvideo/vboxvideo.h
@@ -138,7 +138,7 @@ struct vbva_buffer {
u32 data_len;
/* variable size for the rest of the vbva_buffer area in VRAM. */
- u8 data[0];
+ u8 data[];
} __packed;
#define VBVA_MAX_RECORD_SIZE (128 * 1024 * 1024)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v1] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings
Hi Krishna. Thanks for these bindings files. On Fri, Mar 06, 2020 at 05:06:00PM +0530, Krishna Manikandan wrote: > MSM Mobile Display Subsytem(MDSS) encapsulates sub-blocks > like DPU display controller, DSI etc. Add YAML schema > for the device tree bindings for the same. > > Signed-off-by: Krishna Manikandan > --- > .../bindings/display/msm/dpu-sc7180.yaml | 269 +++ > .../bindings/display/msm/dpu-sdm845.yaml | 265 +++ > .../bindings/display/msm/dsi-sc7180.yaml | 369 > + > .../bindings/display/msm/dsi-sdm845.yaml | 369 > + > 4 files changed, 1272 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-sdm845.yaml > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > new file mode 100644 > index 000..3d1d9b8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > @@ -0,0 +1,269 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Description of Qualcomm Display Dpu dt properties. Try to be cossistent in capitilization of Dpu versus DPU > + > +maintainers: > + - Krishna Manikandan > + > +description: | > + Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates > + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device > tree > + bindings of MDSS and DPU are mentioned for SC7180 target. Bindings should use an indent of two spaces. This is what is used in the example schema and the de-facto standard. One space indent makes it very hard to follow the indent. For examples the indent varies. From 2 spaces to 8 spaces. I often use 4 spaces as 2 spaces is not enough when it spans several lines. But there is nothing fixed there. > + > +properties: > + "mdss": > + type: object > + description: | > + Node containing MDSS that encapsulated sub-blocks like DPU, DSI and DP > + interfaces. > + > + properties: > + compatible: > +items: > + - const: qcom,sc7180-mdss > + reg: > +description: | > + Physical base address and length of controller's registers. Add empty line between properties (empty line before reg:). > + > + reg-names: > +description: | > + Names for different register regions defined above. The required region > + is mentioned below. > +items: > + - const: mdss > + > + power-domains: > +description: | > + A power domain consumer specifier according to > + Documentation/devicetree/bindings/power/power_domain.txt. Should this be power-domain.yaml? > + > + clocks: > +description: | > + List of clock specifiers for clocks needed by the device. Do not use "|" unless required. Fine to have text on same line as description: . Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/edid: Distribute switch variables for initialization
On Fri, Mar 6, 2020 at 9:36 AM Nick Desaulniers wrote:
>
> On Fri, Mar 6, 2020 at 9:32 AM Kees Cook wrote:
> >
> > Variables declared in a switch statement before any case statements
> > cannot be automatically initialized with compiler instrumentation (as
> > they are not part of any execution flow). With GCC's proposed automatic
> > stack variable initialization feature, this triggers a warning (and they
> > don't get initialized). Clang's automatic stack variable initialization
> > (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> > doesn't initialize such variables[1]. Note that these warnings (or silent
>
> That's not good, have you filed a bug against Clang yet? It should at
> least warn when the corresponding stack init flag is set.
D'oh, link is below.
>
> > skipping) happen before the dead-store elimination optimization phase,
> > so even when the automatic initializations are later elided in favor of
> > direct initializations, the warnings remain.
> >
> > To avoid these problems, lift such variables up into the next code
> > block.
> >
> > drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’:
> > drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be
> > executed [-Wswitch-unreachable]
> > 4395 | int sad_count;
> > | ^
> >
> > [1] https://bugs.llvm.org/show_bug.cgi?id=44916
> >
> > Signed-off-by: Kees Cook
>
> Reviewed-by: Nick Desaulniers
>
> > ---
> > v2: move into function block instead being switch-local (Ville Syrjälä)
> > ---
> > drivers/gpu/drm/drm_edid.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 805fb004c8eb..46cee78bc175 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4381,6 +4381,7 @@ static void drm_edid_to_eld(struct drm_connector
> > *connector, struct edid *edid)
> >
> > if (cea_revision(cea) >= 3) {
> > int i, start, end;
> > + int sad_count;
> >
> > if (cea_db_offsets(cea, &start, &end)) {
> > start = 0;
> > @@ -4392,8 +4393,6 @@ static void drm_edid_to_eld(struct drm_connector
> > *connector, struct edid *edid)
> > dbl = cea_db_payload_len(db);
> >
> > switch (cea_db_tag(db)) {
> > - int sad_count;
> > -
> > case AUDIO_BLOCK:
> > /* Audio Data Block, contains SADs */
> > sad_count = min(dbl / 3, 15 -
> > total_sad_count);
> > --
> > 2.20.1
> >
> >
> > --
> > Kees Cook
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Clang Built Linux" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clang-built-linux+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/clang-built-linux/202003060930.DDCCB6659%40keescook.
>
>
>
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/edid: Distribute switch variables for initialization
On Fri, Mar 6, 2020 at 9:32 AM Kees Cook wrote:
>
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization feature, this triggers a warning (and they
> don't get initialized). Clang's automatic stack variable initialization
> (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> doesn't initialize such variables[1]. Note that these warnings (or silent
That's not good, have you filed a bug against Clang yet? It should at
least warn when the corresponding stack init flag is set.
> skipping) happen before the dead-store elimination optimization phase,
> so even when the automatic initializations are later elided in favor of
> direct initializations, the warnings remain.
>
> To avoid these problems, lift such variables up into the next code
> block.
>
> drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’:
> drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be
> executed [-Wswitch-unreachable]
> 4395 | int sad_count;
> | ^
>
> [1] https://bugs.llvm.org/show_bug.cgi?id=44916
>
> Signed-off-by: Kees Cook
Reviewed-by: Nick Desaulniers
> ---
> v2: move into function block instead being switch-local (Ville Syrjälä)
> ---
> drivers/gpu/drm/drm_edid.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 805fb004c8eb..46cee78bc175 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4381,6 +4381,7 @@ static void drm_edid_to_eld(struct drm_connector
> *connector, struct edid *edid)
>
> if (cea_revision(cea) >= 3) {
> int i, start, end;
> + int sad_count;
>
> if (cea_db_offsets(cea, &start, &end)) {
> start = 0;
> @@ -4392,8 +4393,6 @@ static void drm_edid_to_eld(struct drm_connector
> *connector, struct edid *edid)
> dbl = cea_db_payload_len(db);
>
> switch (cea_db_tag(db)) {
> - int sad_count;
> -
> case AUDIO_BLOCK:
> /* Audio Data Block, contains SADs */
> sad_count = min(dbl / 3, 15 -
> total_sad_count);
> --
> 2.20.1
>
>
> --
> Kees Cook
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/202003060930.DDCCB6659%40keescook.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: komeda: Make rt_pm_ops dependent on CONFIG_PM
Hi James, On 3/6/20 4:14 AM, james qian wang (Arm Technology China) wrote: > On Fri, Mar 06, 2020 at 02:42:55AM +0800, Liviu Dudau wrote: >> On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote: >>> komeda_rt_pm_suspend() and komeda_rt_pm_resume() are compiled only when >>> CONFIG_PM is enabled. Having it disabled triggers the following warning >>> at compile time: >>> >>> linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12: >>> warning: ‘komeda_rt_pm_resume’ defined but not used [-Wunused-function] >>> static int komeda_rt_pm_resume(struct device *dev) >>> ^~~ >>> linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:149:12: >>> warning: ‘komeda_rt_pm_suspend’ defined but not used [-Wunused-function] >>> static int komeda_rt_pm_suspend(struct device *dev) >>> >>> Make komeda_rt_pm_suspend() and komeda_rt_pm_resume() dependent on >>> CONFIG_PM to address the issue. >>> >>> Cc: "James (Qian) Wang" >>> Cc: Liviu Dudau >>> Cc: Mihail Atanassov >>> Cc: Brian Starkey >>> Cc: David Airlie >>> Cc: Daniel Vetter >>> Signed-off-by: Vincenzo Frascino >> > > Hi Vincenzo: > > Thanks for the patch. > > and Vincenzo & Liviu, sorry > > Since there is a patch for this problem already: > https://patchwork.freedesktop.org/series/71721/ > > And I have pushed that old fix to drm-misc-fixes just before I saw > this mail. sorry. > No issue, as far as it is fixed :) It is annoying stepping on it during randconfig :) Thanks for letting me know! [...] -- Regards, Vincenzo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: bufs: Clean up documentation
Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/drm_bufs.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index 19297e58b232..dcabf5698333 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -134,7 +134,7 @@ static int drm_map_handle(struct drm_device *dev, struct drm_hash_item *hash, shift, add); } -/** +/* * Core function to create a range of memory available for mapping by a * non-root process. * @@ -398,7 +398,7 @@ struct drm_local_map *drm_legacy_findmap(struct drm_device *dev, } EXPORT_SYMBOL(drm_legacy_findmap); -/** +/* * Ioctl to specify a range of memory that is available for mapping by a * non-root process. * @@ -499,7 +499,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void *data, return 0; } -/** +/* * Remove a map private from list and deallocate resources if the mapping * isn't in use. * @@ -659,7 +659,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void *data, return ret; } -/** +/* * Cleanup after an error on one of the addbufs() functions. * * \param dev DRM device. @@ -694,7 +694,7 @@ static void drm_cleanup_buf_error(struct drm_device *dev, } #if IS_ENABLED(CONFIG_AGP) -/** +/* * Add AGP buffers for DMA transfers. * * \param dev struct drm_device to which the buffers are to be added. @@ -1230,7 +1230,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev, return 0; } -/** +/* * Add buffers for DMA transfers (ioctl). * * \param inode device inode. @@ -1271,7 +1271,7 @@ int drm_legacy_addbufs(struct drm_device *dev, void *data, return ret; } -/** +/* * Get information about the buffer mappings. * * This was originally mean for debugging purposes, or by a sophisticated @@ -1362,7 +1362,7 @@ int drm_legacy_infobufs(struct drm_device *dev, void *data, return __drm_legacy_infobufs(dev, data, &request->count, copy_one_buf); } -/** +/* * Specifies a low and high water mark for buffer allocation * * \param inode device inode. @@ -1411,7 +1411,7 @@ int drm_legacy_markbufs(struct drm_device *dev, void *data, return 0; } -/** +/* * Unreserve the buffers in list, previously reserved using drmDMA. * * \param inode device inode. @@ -1463,7 +1463,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data, return 0; } -/** +/* * Maps all of the DMA buffers into client-virtual space (ioctl). * * \param inode device inode. -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] display/bridge: dsi2lvds tc358775 driver
hi andrzej,
I had a doubt In the tc358764 driver,VP_CTRL, VP_CTRL_VSDELAY(15) is
hardcoded to 15, but this has to be dynamic based on the resolution of
panel used?
Please see the reply inline.
On Tue, Mar 3, 2020 at 8:39 PM Andrzej Hajda wrote:
>
> On 27.02.2020 15:03, Vinay Simha BN wrote:
> > dsi2lvds tc358775 bridge driver added
> > Tested in apq8016, ifc6309 board and panel
> > auo,b101xtn01
>
>
> Just FYI, there exists already TC358764/5 driver for similar hw, but
> controlled via DSI bus.
There is not much difference between these two chips, but still the
dsi read access for 775 does not works.
TC358764/5 - 800Mbps per lane, 3.2Gbps
TC358775 - 1Gbps per lane, 4Gbps.
tc358775 chip details -
https://download.t-firefly.com/product/RK3399/Docs/Chip%20Specifications/TC358774XBG_75XBG_V1%204nm.pdf
I am able to configure the tc358775 chip by i2c, but from dsi it fails
i tried accessing the tc358775 chip by dsi using apq8016-qcom , but it
fails to read the chip id itself.
Please suggest if you any inputs for this issue.
https://github.com/vinaysimhabn/kernel-msm/commits/5.6.0-rc3-dsi2lvds-dsi
[4.582405] tc358764 1a98000.dsi.0: read: 1408, addr: 0
[4.582426] tc358764 1a98000.dsi.0: ID: 0x0
[4.582451] tc358764 1a98000.dsi.0: error initializing bridge (-22)
[4.796220] dsi_cmds2buf_tx: cmd dma tx failed, type=0x24, data0=0x80, len=4
[4.796244] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0
[4.796266] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0
[4.796288] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0
[4.796310] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0
[4.796319] msm_dsi_host_cmd_rx:Invalid response cmd
>
>
> > Signed-off-by: Vinay Simha BN
> > ---
> > .../bindings/display/bridge/toshiba,tc358775.txt | 106
>
>
> Bindings should be in separate patch and in yaml format.
>
>
> > drivers/gpu/drm/bridge/Kconfig | 10 +
> > drivers/gpu/drm/bridge/Makefile| 1 +
> > drivers/gpu/drm/bridge/tc358775.c | 687
> > +
> > 4 files changed, 804 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt
> > create mode 100644 drivers/gpu/drm/bridge/tc358775.c
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt
> > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt
> > new file mode 100644
> > index 000..c4c364d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt
> > @@ -0,0 +1,106 @@
> > +Toshiba TC358775 DSI to LVDS bridge bindings
> > +
> > +Required properties:
> > + - compatible: "toshiba,tc358775"
> > + - reg: i2c address of the bridge, 0x0f
> > + - tc, dsi-lanes: Number of DSI data lanes connected to the DSI host. It
> > should
> > + be one of 1, 2, 3 or 4.
> > + - tc, dual-link : To configure the LVDS transmitter either
> > + as single-link or dual-link.
> > + - tc, data-format: To configure the data formats
> > + 0 for VESA standard, 1 for JEIDA standard
>
>
> IMO, three properties above should be received from downstream device in
> runtime, not hardcoded into DT, however I am not sure if frameworks
> support it.
>
> > + - vdd-supply: 1.2V LVDS Power Supply
> > + - vddio-supply: 1.8V IO Power Supply
> > + - stby-gpios: Standby pin, Low active
> > + - reset-gpios: Hardware reset, Low active
> > +
> > +Required nodes:
> > +
> > +The TC358775 has two ports. Their connections are modelled using the OF
> > +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > +
> > +- Video port 0 for the DSI input. The remote endpoint phandle should be a
> > + reference to a valid mipi_dsi_host device node.
> > +- Video port 1 for the LVDS output.
> > +
> > +Example:
> > +
> > + i2c@78b8000 {
> > + /* On High speed expansion */
> > + label = "HS-I2C2";
> > + status = "okay";
> > +
> > + tc_bridge: bridge@f {
> > + status = "okay";
> > +
> > + compatible = "toshiba,tc358775";
> > + reg = <0x0f>;
> > +
> > + tc,dsi-lanes = <4>;
> > + tc,dual-link = <0>;
> > + tc,data-format = <1>;
> > +
> > + vdd-supply = <&pm8916_l2>;
> > + vddio-supply = <&pm8916_l6>;
> > +
> > + stby-gpio = <&msmgpio 99 GPIO_ACTIVE_LOW>;
> > + reset-gpio = <&msmgpio 72 GPIO_ACTIVE_LOW>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + d2l_in: endpoint {
> > +
Re: [PATCH v5 0/4] Add dts for mt8183 GPU (and misc panfrost patches)
Series has my r-b :) On Fri, Mar 06, 2020 at 12:13:41PM +0800, Nicolas Boichat wrote: > Hi! > > Follow-up on the v4: https://patchwork.kernel.org/cover/11369777/, some > of the core patches got merged already (thanks Rob!). > > The main purpose of this series is to upstream the dts change and the > binding document, but I wanted to see how far I could probe the GPU, to > check that the binding is indeed correct. The rest of the patches are > RFC/work-in-progress. > > So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of > backports to get the latest panfrost driver (I should probably try on > linux-next at some point but this was the path of least resistance). > > I tested it as a module as it's more challenging (originally probing would > work built-in, on boot, but not as a module, as I didn't have the power > domain changes, and all power domains are on by default during boot). > > Probing logs looks like this, currently. They look sane. > [ 501.319728] panfrost 1304.gpu: clock rate = 51170 > [ 501.320041] panfrost 1304.gpu: Linked as a consumer to regulator.14 > [ 501.320102] panfrost 1304.gpu: Linked as a consumer to regulator.31 > [ 501.320651] panfrost 1304.gpu: Linked as a consumer to > genpd:0:1304.gpu > [ 501.320954] panfrost 1304.gpu: Linked as a consumer to > genpd:1:1304.gpu > [ 501.321062] panfrost 1304.gpu: Linked as a consumer to > genpd:2:1304.gpu > [ 501.321734] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 > status 0x0 > [ 501.321741] panfrost 1304.gpu: features: ,13de77ff, issues: > ,0400 > [ 501.321747] panfrost 1304.gpu: Features: L2:0x07120206 > Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7 > [ 501.321752] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1 > [ 501.324951] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on > minor 2 > > Some more changes are still required to get devfreq working, and of course > I do not have a userspace driver to test this with. > > I believe at least patches 1 & 2 can be merged (2 depends on another > patch series, so maybe we could start with 1 only for now...). > > Thanks! > > Nicolas Boichat (4): > dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 > arm64: dts: mt8183: Add node for the Mali GPU > RFC: drm/panfrost: Add mt8183-mali compatible string > RFC: drm/panfrost: devfreq: Add support for 2 regulators > > .../bindings/gpu/arm,mali-bifrost.yaml| 25 + > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++ > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 17 +++ > drivers/gpu/drm/panfrost/panfrost_device.h| 1 + > drivers/gpu/drm/panfrost/panfrost_drv.c | 11 ++ > 6 files changed, 166 insertions(+) > > -- > 2.25.1.481.gfbce0eb801-goog > signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On 6/3/20 13:03, Ondřej Jirman wrote: > On Fri, Mar 06, 2020 at 09:46:51AM +0100, Enric Balletbo i Serra wrote: >> Hi Ondrej, >> >> On 5/3/20 20:35, Ondřej Jirman wrote: >>> Hi, >>> >>> On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra wrote: > > Hi Vasily, CC: Icenowy and Ondrej > > Would you mind to check which firmware version is running the anx7688 in > PinePhone, I think should be easy to check with i2c-tools. Icenowy, Ondrej, can you guys please check anx7688 firmware version? >>> >>> i2cget 0 0x28 0x00 w >>> 0x >>> >>> i2cget 0 0x28 0x02 w >>> 0x7688 >>> >>> i2cget 0 0x28 0x80 w >>> 0x >>> >> >> Can you check the value for 0x81 too? > > 'w' read checks both values at once, as you can see above. > Oh right, sorry. The thing is that firmware version is at 0x2c, not 0x28, so we're interested on see register 0x80 and 0x81 for 0x2c address. Thanks, Enric > regards, > o. > >> Thanks, >> Enric >> >> >>> regards, >>> o. >>> > Thanks in advance, > Enric > > [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v7] dt-bindings: display: Add idk-2121wr binding
From: Fabrizio Castro
Add binding for the idk-2121wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro
Signed-off-by: Lad Prabhakar
---
Apologies for flooding in I missed to add the ML email-ids for the earlier
version so resending it.
Hi All,
This patch is part of series [1] ("Add dual-LVDS panel support to EK874),
all the patches have been accepted from it except this one. I have fixed
Rob's comments in this version of the patch.
[1] https://patchwork.kernel.org/cover/11297589/
v6->7
* Added reference to lvds.yaml
* Changed maintainer to myself
* Switched to dual license
* Dropped required properties except for ports as rest are already listed
in lvds.panel
* Dropped Reviewed-by tag of Laurent, due to the changes made it might not
be valid.
v5->v6:
* No change
v4->v5:
* No change
v3->v4:
* Absorbed patch "dt-bindings: display: Add bindings for LVDS
bus-timings"
* Big restructuring after Rob's and Laurent's comments
v2->v3:
* New patch
.../display/panel/advantech,idk-2121wr.yaml| 120 +
1 file changed, 120 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
new file mode 100644
index 000..b05df05
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
+
+maintainers:
+ - Lad Prabhakar
+ - Thierry Reding
+
+description: |
+ The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
+ A dual-LVDS interface is a dual-link connection with even pixels traveling
+ on one link, and with odd pixels traveling on the other link.
+
+ The panel expects odd pixels on the first port, and even pixels on the
+ second port, therefore the ports must be marked accordingly (with either
+ dual-lvds-odd-pixels or dual-lvds-even-pixels).
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ compatible:
+items:
+ - const: advantech,idk-2121wr
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ width-mm:
+const: 476
+
+ height-mm:
+const: 268
+
+ data-mapping:
+const: vesa-24
+
+ ports:
+type: object
+properties:
+ port@0:
+type: object
+description: The sink for odd pixels.
+properties:
+ reg:
+const: 0
+
+ dual-lvds-odd-pixels: true
+
+required:
+ - reg
+ - dual-lvds-odd-pixels
+
+ port@1:
+type: object
+description: The sink for even pixels.
+properties:
+ reg:
+const: 1
+
+ dual-lvds-even-pixels: true
+
+required:
+ - reg
+ - dual-lvds-even-pixels
+
+ panel-timing: true
+
+additionalProperties: false
+
+required:
+ - ports
+
+examples:
+ - |+
+panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+clock-frequency = <14850>;
+hactive = <1920>;
+vactive = <1080>;
+hsync-len = <44>;
+hfront-porch = <88>;
+hback-porch = <148>;
+vfront-porch = <4>;
+vback-porch = <36>;
+vsync-len = <5>;
+ };
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+remote-endpoint = <&lvds0_out>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+remote-endpoint = <&lvds1_out>;
+ };
+};
+ };
+};
+
+...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v1] dt-bindings: msm:disp: update dsi and dpu bindings
On 2020-02-04 23:52, Doug Anderson wrote:
Hi,
On Tue, Feb 4, 2020 at 6:15 AM Harigovindan P
wrote:
Updating bindings of dsi and dpu by adding and removing certain
properties.
Signed-off-by: Harigovindan P
---
Changes in v1:
- Adding "ahb" clock as a required property.
- Adding "bus", "rot", "lut" as optional properties for sc7180
device.
- Removing properties from dsi bindings that are unused.
- Removing power-domain property since DSI is the child node
of MDSS
and it will inherit supply from its parent.
Documentation/devicetree/bindings/display/msm/dpu.txt | 7 +++
Documentation/devicetree/bindings/display/msm/dsi.txt | 5 -
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index 551ae26..dd58472a 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -19,6 +19,7 @@ Required properties:
The following clocks are required:
* "iface"
* "bus"
+ * "ahb"
This is only required for sc7180? ...or old SoCs should have had it
all along too?
* "core"
- interrupts: interrupt signal from MDSS.
- interrupt-controller: identifies the node as an interrupt
controller.
@@ -50,6 +51,8 @@ Required properties:
- clock-names: device clock names, must be in same order as clocks
property.
The following clocks are required.
* "bus"
+ For the device "qcom,sc7180-dpu":
+ * "bus" - is an optional property due to architecture change.
This is a really odd way to write it for two reasons:
* You're breaking up the flow of the list.
* This shouldn't be listed as "optional" in sc7180 but unless there is
some reason to ever provide it on sc7180. It should simply be
disallowed.
Maybe instead just:
The following clocks are required.
- * "bus"
+ * "bus" (anything other than qcom,sc7180-dpu)
We really need to get this into yaml ASAP but that'd probably be OK to
tide us over.
NOTE: when converting to yaml, ideally we'll have a separate file per
SoC to avoid crazy spaghetti, see commit 2a8aa18c1131 ("dt-bindings:
clk: qcom: Fix self-validation, split, and clean cruft") in clk-next
for an example of starting the transition to one yaml per SoC (at
least for anything majorly different).
* "iface"
* "core"
* "vsync"
@@ -70,6 +73,10 @@ Optional properties:
- assigned-clocks: list of clock specifiers for clocks needing rate
assignment
- assigned-clock-rates: list of clock frequencies sorted in the same
order as
the assigned-clocks property.
+- For the device "qcom,sc7180-dpu":
+ clock-names: optional device clocks, needed for accessing LUT
blocks.
+ * "rot"
+ * "lut"
Example:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index af95586..61d659a 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -8,13 +8,10 @@ Required properties:
- reg-names: The names of register regions. The following regions are
required:
* "dsi_ctrl"
- interrupts: The interrupt signal from the DSI block.
-- power-domains: Should be <&mmcc MDSS_GDSC>.
Is this supposed to be removed from all SoCs using this bindings, or
just yours?
I'll also note that you left it in the "Example:" below.
- clocks: Phandles to device clocks.
- clock-names: the following clocks are required:
- * "mdp_core"
* "iface"
* "bus"
- * "core_mmss"
As Jeffrey pointed out, you shouldn't be removing these from old SoCs.
In "drivers/gpu/drm/msm/dsi/dsi_cfg.c" you can clearly see them used.
Maybe it's time for you to do the yaml conversion and handle this
correctly per-SoC.
-Doug
Hi,
yaml files have been created and new patchset has been created for that.
https://patchwork.kernel.org/patch/11423653/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Fri, Mar 06, 2020 at 09:46:51AM +0100, Enric Balletbo i Serra wrote: > Hi Ondrej, > > On 5/3/20 20:35, Ondřej Jirman wrote: > > Hi, > > > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: > >> On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > >> wrote: > >>> > >>> Hi Vasily, > >> > >> CC: Icenowy and Ondrej > >>> > >>> Would you mind to check which firmware version is running the anx7688 in > >>> PinePhone, I think should be easy to check with i2c-tools. > >> > >> Icenowy, Ondrej, can you guys please check anx7688 firmware version? > > > > i2cget 0 0x28 0x00 w > > 0x > > > > i2cget 0 0x28 0x02 w > > 0x7688 > > > > i2cget 0 0x28 0x80 w > > 0x > > > > Can you check the value for 0x81 too? 'w' read checks both values at once, as you can see above. regards, o. > Thanks, > Enric > > > > regards, > > o. > > > >>> Thanks in advance, > >>> Enric > >>> > >>> [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: context: Clean up documentation
Fix kernel doc comments to avoid warnings when compiling with W=1.
Signed-off-by: Benjamin Gaignard
---
version 2:
- Since it is legacy interface do not fix the description but
replace /** by /* to remove kerneldoc validation warnings
drivers/gpu/drm/drm_context.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 1f802d8e5681..c99be950bf17 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -47,7 +47,7 @@ struct drm_ctx_list {
/** \name Context bitmap support */
/*@{*/
-/**
+/*
* Free a handle from the context bitmap.
*
* \param dev DRM device.
@@ -68,7 +68,7 @@ void drm_legacy_ctxbitmap_free(struct drm_device * dev, int
ctx_handle)
mutex_unlock(&dev->struct_mutex);
}
-/**
+/*
* Context bitmap allocation.
*
* \param dev DRM device.
@@ -88,7 +88,7 @@ static int drm_legacy_ctxbitmap_next(struct drm_device * dev)
return ret;
}
-/**
+/*
* Context bitmap initialization.
*
* \param dev DRM device.
@@ -104,7 +104,7 @@ void drm_legacy_ctxbitmap_init(struct drm_device * dev)
idr_init(&dev->ctx_idr);
}
-/**
+/*
* Context bitmap cleanup.
*
* \param dev DRM device.
@@ -163,7 +163,7 @@ void drm_legacy_ctxbitmap_flush(struct drm_device *dev,
struct drm_file *file)
/** \name Per Context SAREA Support */
/*@{*/
-/**
+/*
* Get per-context SAREA.
*
* \param inode device inode.
@@ -211,7 +211,7 @@ int drm_legacy_getsareactx(struct drm_device *dev, void
*data,
return 0;
}
-/**
+/*
* Set per-context SAREA.
*
* \param inode device inode.
@@ -263,7 +263,7 @@ int drm_legacy_setsareactx(struct drm_device *dev, void
*data,
/** \name The actual DRM context handling routines */
/*@{*/
-/**
+/*
* Switch context.
*
* \param dev DRM device.
@@ -290,7 +290,7 @@ static int drm_context_switch(struct drm_device * dev, int
old, int new)
return 0;
}
-/**
+/*
* Complete context switch.
*
* \param dev DRM device.
@@ -318,7 +318,7 @@ static int drm_context_switch_complete(struct drm_device
*dev,
return 0;
}
-/**
+/*
* Reserve contexts.
*
* \param inode device inode.
@@ -351,7 +351,7 @@ int drm_legacy_resctx(struct drm_device *dev, void *data,
return 0;
}
-/**
+/*
* Add context.
*
* \param inode device inode.
@@ -404,7 +404,7 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
return 0;
}
-/**
+/*
* Get context.
*
* \param inode device inode.
@@ -428,7 +428,7 @@ int drm_legacy_getctx(struct drm_device *dev, void *data,
return 0;
}
-/**
+/*
* Switch context.
*
* \param inode device inode.
@@ -452,7 +452,7 @@ int drm_legacy_switchctx(struct drm_device *dev, void *data,
return drm_context_switch(dev, dev->last_context, ctx->handle);
}
-/**
+/*
* New context.
*
* \param inode device inode.
@@ -478,7 +478,7 @@ int drm_legacy_newctx(struct drm_device *dev, void *data,
return 0;
}
-/**
+/*
* Remove context.
*
* \param inode device inode.
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: rcar-du: make all sub-symbols depend on DRM_RCAR_DU
On 3/6/20 6:28 AM, Laurent Pinchart wrote: > Hi Randy, > > On Thu, Mar 05, 2020 at 07:17:49PM -0800, Randy Dunlap wrote: >> From: Randy Dunlap >> >> DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig >> symbols do not depend on DRM_RCAR_DU, the menu presentation is >> broken for these and following non-R-Car Kconfig symbols. >> >> Is it safe/appropriate to make all of these symbols depend on >> DRM_RCAR_DU? It make the kconfig menu presentation much cleaner. > > As those drivers are useless without DRM_RCAR_DU, I'm fine with this > change. It however prevents test-compiling those drivers when > DRM_RCAR_DU is disabled, but I see little reason to do so anyway, I > expect compile tests to aim for as large coverage as possible, and they > should thus enable DRM_RCAR_DU. > > Would you like to submit a new version without this question, and > possibly addressing Geert's concern if you think it's appropriate, or > should I do so when applying ? > >> Signed-off-by: Randy Dunlap >> Cc: Laurent Pinchart >> Cc: Kieran Bingham >> Cc: dri-devel@lists.freedesktop.org >> Cc: linux-renesas-...@vger.kernel.org >> Cc: Koji Matsuoka >> Cc: Dave Airlie >> --- >> drivers/gpu/drm/rcar-du/Kconfig |3 +++ >> 1 file changed, 3 insertions(+) >> >> --- linux-next-20200305.orig/drivers/gpu/drm/rcar-du/Kconfig >> +++ linux-next-20200305/drivers/gpu/drm/rcar-du/Kconfig >> @@ -24,6 +24,7 @@ config DRM_RCAR_CMM >> config DRM_RCAR_DW_HDMI >> tristate "R-Car DU Gen3 HDMI Encoder Support" >> depends on DRM && OF >> +depends on DRM_RCAR_DU >> select DRM_DW_HDMI >> help >>Enable support for R-Car Gen3 internal HDMI encoder. >> @@ -31,6 +32,7 @@ config DRM_RCAR_DW_HDMI >> config DRM_RCAR_LVDS >> tristate "R-Car DU LVDS Encoder Support" >> depends on DRM && DRM_BRIDGE && OF >> +depends on DRM_RCAR_DU >> select DRM_PANEL >> select OF_FLATTREE >> select OF_OVERLAY >> @@ -47,4 +49,5 @@ config DRM_RCAR_VSP >> >> config DRM_RCAR_WRITEBACK >> bool >> +depends on DRM_RCAR_DU >> default y if ARM64 > > Is this one needed ? The symbol should not be shown in the kconfig menu > as it has no text. Hi Laurent, I tried the patch without that line as my first attempt and there was still a problem with the menu, so I will resubmit the patch using a block as Geert suggested. thanks. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] drm/bridge: anx7688: Add ANX7688 bridge driver support
From: Nicolas Boichat
This driver adds support for the ANX7688 HDMI to DP converter block of the
ANX7688 multi-function device.
For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count are reported by the bridge via
2 registers and, as far as we know, only for chips that have a firmware
version greather than 0.85 supports these two registers.
Signed-off-by: Nicolas Boichat
Signed-off-by: Hsin-Yi Wang
Signed-off-by: Enric Balletbo i Serra
---
Changes in v3:
- Convert to a child of ANX7688 multi-function device.
Changes in v2:
- Move driver to drivers/gpu/drm/bridge/analogix.
- Make the driver OF only so we can reduce the ifdefs.
- Update the Copyright to 2020.
- Use probe_new so we can get rid of the i2c_device_id table.
drivers/gpu/drm/bridge/analogix/Kconfig | 9 ++
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../drm/bridge/analogix/analogix-anx7688.c| 135 ++
3 files changed, 145 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e1fa7d820373..02c420ba79bd 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -11,6 +11,15 @@ config DRM_ANALOGIX_ANX6345
ANX6345 transforms the LVTTL RGB output of an
application processor to eDP or DisplayPort.
+config DRM_ANALOGIX_ANX7688
+ tristate "Analogix ANX7688 bridge"
+ select DRM_KMS_HELPER
+ select MFD_ANX7688
+ help
+ ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
+ mobile HD transmitter designed for portable devices. The
+ ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD.
+
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index 97669b374098..27cd73635c8c 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
new file mode 100644
index ..81b950ecde27
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2020 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct anx7688_bridge_data {
+ struct drm_bridge bridge;
+ struct regmap *regmap;
+
+ bool filter;
+};
+
+static inline struct anx7688_bridge_data *
+bridge_to_anx7688(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct anx7688_bridge_data, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct anx7688_bridge_data *data = bridge_to_anx7688(bridge);
+ int totalbw, requiredbw;
+ u8 dpbw, lanecount;
+ u8 regs[2];
+ int ret;
+
+ if (!data->filter)
+ return true;
+
+ /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+ ret = regmap_bulk_read(data->regmap, ANX7688_DP_BANDWIDTH_REG, regs,
+ 2);
+ if (ret < 0) {
+ DRM_ERROR("Failed to read bandwidth/lane count\n");
+ return false;
+ }
+ dpbw = regs[0];
+ lanecount = regs[1];
+
+ /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+ if (dpbw > 0x19 || lanecount > 2) {
+ DRM_ERROR("Invalid bandwidth/lane count (%02x/%d)\n", dpbw,
+ lanecount);
+ return false;
+ }
+
+ /* Compute available bandwidth (kHz) */
+ totalbw = dpbw * lanecount * 27 * 8 / 10;
+
+ /* Required bandwidth (8 bpc, kHz) */
+ requiredbw = mode->clock * 8 * 3;
+
+ DRM_DEBUG_KMS("DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n",
+ totalbw, dpbw, lanecount, requiredbw);
+
+ if (totalbw == 0) {
+ DRM_ERROR("Bandwidth/lane count are 0, not rejecting modes\n");
+ return true;
+ }
+
+ return totalbw >= requiredbw;
+}
+
+static const struct drm_bridge_funcs anx7688_brid
[PATCH v2] drm: rcar-du: make all sub-symbols depend on DRM_RCAR_DU
From: Randy Dunlap DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig symbols do not depend on DRM_RCAR_DU, the menu presentation is broken for these and following non-R-Car Kconfig symbols. Use an if/endif block to make all of these symbols depend on DRM_RCAR_DU (and remove the separate "depends on DRM_RCAR_DU"). This makes the kconfig menu presentation much cleaner. Signed-off-by: Randy Dunlap Cc: Laurent Pinchart Cc: Kieran Bingham Cc: dri-devel@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: Koji Matsuoka Cc: David Airlie Cc: Geert Uytterhoeven --- v2: use an if/endif block for the dependencies (thanks, Geert) drivers/gpu/drm/rcar-du/Kconfig |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) --- linux-next-20200305.orig/drivers/gpu/drm/rcar-du/Kconfig +++ linux-next-20200305/drivers/gpu/drm/rcar-du/Kconfig @@ -14,10 +14,11 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. +if DRM_RCAR_DU + config DRM_RCAR_CMM tristate "R-Car DU Color Management Module (CMM) Support" depends on DRM && OF - depends on DRM_RCAR_DU help Enable support for R-Car Color Management Module (CMM). @@ -40,7 +41,6 @@ config DRM_RCAR_LVDS config DRM_RCAR_VSP bool "R-Car DU VSP Compositor Support" if ARM default y if ARM64 - depends on DRM_RCAR_DU depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m) help Enable support to expose the R-Car VSP Compositor as KMS planes. @@ -48,3 +48,5 @@ config DRM_RCAR_VSP config DRM_RCAR_WRITEBACK bool default y if ARM64 + +endif # DRM_RCAR_DU ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: lock: Clean up documentation
Fix kernel doc comments to avoid warnings when compiling with W=1.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_lock.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 2c79e8199e3c..f16eefbf2829 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -46,7 +46,7 @@
static int drm_lock_take(struct drm_lock_data *lock_data, unsigned int
context);
-/**
+/*
* Take the heavyweight lock.
*
* \param lock lock pointer.
@@ -93,7 +93,7 @@ int drm_lock_take(struct drm_lock_data *lock_data,
return 0;
}
-/**
+/*
* This takes a lock forcibly and hands it to context. Should ONLY be used
* inside *_unlock to give lock to kernel before calling *_dma_schedule.
*
@@ -150,7 +150,7 @@ static int drm_legacy_lock_free(struct drm_lock_data
*lock_data,
return 0;
}
-/**
+/*
* Lock ioctl.
*
* \param inode device inode.
@@ -243,7 +243,7 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
return 0;
}
-/**
+/*
* Unlock ioctl.
*
* \param inode device inode.
@@ -275,7 +275,7 @@ int drm_legacy_unlock(struct drm_device *dev, void *data,
struct drm_file *file_
return 0;
}
-/**
+/*
* This function returns immediately and takes the hw lock
* with the kernel context if it is free, otherwise it gets the highest
priority when and if
* it is eventually released.
@@ -287,7 +287,6 @@ int drm_legacy_unlock(struct drm_device *dev, void *data,
struct drm_file *file_
* This should be sufficient to wait for GPU idle without
* having to worry about starvation.
*/
-
void drm_legacy_idlelock_take(struct drm_lock_data *lock_data)
{
int ret;
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] dt-bindings: Add ANX7688 HDMI to DP bridge binding
From: Nicolas Boichat
Add documentation for DT properties supported by the ANX7688 HDMI-DP
converter.
Signed-off-by: Nicolas Boichat
Signed-off-by: Hsin-Yi Wang
Signed-off-by: Enric Balletbo i Serra
---
Changes in v3:
- Adapt the bridge bindings for the multi-function device.
Changes in v2:
- Improve a bit the descriptions using the info from the datasheet.
- Convert binding to yaml.
- Use dual licensing.
.../bridge/analogix,anx7688-bridge.yaml | 80 +++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix,anx7688-bridge.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7688-bridge.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7688-bridge.yaml
new file mode 100644
index ..c56da3f39dd8
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7688-bridge.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/analogix,anx7688-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analogix ANX7688 HDMI to DisplayPort Bridge
+
+maintainers:
+ - Nicolas Boichat
+ - Enric Balletbo i Serra
+
+description: |
+ The ANX7688 bridge describes the HDMI 2.0 to DisplayPort 1.3 bridge block
+ included in the ANX7688 chip controller. These are meant to be used for
+ controlling display-related signals.
+
+ The node of this device should be under an analogix,anx7866 node. Please
refer
+ to Documentation/devicetree/bindings/mfd/analogix,anx7688.yaml for the
ANX7688
+ core bindings.
+
+properties:
+ compatible:
+const: analogix,anx7688-bridge
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for HDMI input
+
+ port@1:
+type: object
+description: |
+ Video port for DP output
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - ports
+
+examples:
+ - |
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+anx7688: anx7688@2c {
+compatible = "analogix,anx7688";
+reg = <0x2c>;
+
+bridge {
+compatible = "analogix,anx7688-bridge";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+anx7688_in: endpoint {
+remote-endpoint = <&hdmi0_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+anx7688_out: endpoint {
+remote-endpoint = <&typec0_connector>;
+ };
+};
+};
+};
+};
+};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Fri, Mar 06, 2020 at 04:53:46PM +0800, Icenowy Zheng wrote: > 在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道： > > Hi Ondrej, > > > > On 5/3/20 20:35, Ondřej Jirman wrote: > > > Hi, > > > > > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: > > > > On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > > > > wrote: > > > > > Hi Vasily, > > > > > > > > CC: Icenowy and Ondrej > > > > > Would you mind to check which firmware version is running the > > > > > anx7688 in > > > > > PinePhone, I think should be easy to check with i2c-tools. > > > > > > > > Icenowy, Ondrej, can you guys please check anx7688 firmware > > > > version? > > > > > > i2cget 0 0x28 0x00 w > > > 0x > > > > > > i2cget 0 0x28 0x02 w > > > 0x7688 > > > > > > i2cget 0 0x28 0x80 w > > > 0x > > > > > > > Can you check the value for 0x81 too? > > root@ice-pinephone [ ~ ] # i2cdump 0 0x28 > No size specified (using byte-data access) > WARNING! This program can confuse your I2C bus, cause data loss and > worse! > I will probe file /dev/i2c-0, address 0x28, mode byte > Continue? [Y/n] > 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef > 00: aa aa 88 76 ac 00 00 00 00 00 00 00 00 00 05 05???v?.?? > 10: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000... > 20: 00 00 00 00 00 00 00 00 00 00 00 24 f2 e4 ff 00...$??.. > 30: 06 40 00 04 94 11 20 ff ff 03 00 bf ff ff 10 01?@.??? ..?.?..?? > 40: 72 a4 00 09 00 08 05 84 15 40 17 00 00 0a 00 e0r?.?.@?..?.? > 50: 00 00 00 0a 10 00 e0 df ff ff 00 00 00 10 71 00...??.??.?q. > 60: 10 10 04 29 2d 21 10 01 09 13 00 03 e8 13 88 00???)-!.. > 70: 00 19 18 83 16 5c 11 00 ff 00 00 0d 04 38 42 07.\???8B? > 80: 00 00 00 00 00 74 1b 19 44 08 75 00 00 00 00 00.t??D?u. > 90: 01 02 00 00 00 00 03 00 ff 30 00 59 01 00 00 00???..0.Y?... > a0: 00 ff fe ff ff 00 00 00 00 00 00 00 00 00 00 02..?? > b0: 00 00 00 00 00 00 40 00 28 00 00 00 00 44 08 00..@.(D?. > c0: 00 00 00 00 80 00 10 01 0a 10 18 00 00 fd 00 00?.?..?.. > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 50 10 08 50 00 02 00 70 00 00 30 10 0b 02 1c 01P??P.?.p..0? > f0: 00 0b 07 00 94 11 7f 00 00 00 00 00 00 01 0e ff.??.???..??. My values for 0x28 address match this. ^ Interesting that it returns different register values for different device addresses. > root@ice-pinephone [ ~ ] # i2cdump 0 0x2c > No size specified (using byte-data access) > WARNING! This program can confuse your I2C bus, cause data loss and > worse! > I will probe file /dev/i2c-0, address 0x2c, mode byte > Continue? [Y/n] > 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef > 00: 29 1f 88 76 00 ac 11 00 11 20 10 10 00 00 00 00)??v.??.? ?? > 10: 03 00 ff 8f ff 7f 00 00 00 00 05 00 10 0a 0c 00?..?.??.???. > 20: 00 00 00 00 99 06 c0 00 00 00 00 00 00 00 02 00???...?. > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 40: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... > 80: 01 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00?%.. > 90: 0f 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00??.. > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > > Thanks, > > Enric > > > > > > > regards, > > > o. > > > > > > > > Thanks in advance, > > > > > Enric > > > > > > > > > > [snip] > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] Add support for rm69299 Visionox panel driver and add devicetree bindings for visionox panel
Adding support for visionox rm69299 panel driver and adding bindings for the same panel. Harigovindan P (2): dt-bindings: display: add visionox rm69299 panel variant drm/panel: add support for rm69299 visionox panel driver .../display/panel/visionox,rm69299.yaml | 85 + drivers/gpu/drm/panel/Kconfig | 8 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-visionox-rm69299.c| 322 ++ 4 files changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
KASAN: use-after-free Read in dmabuffs_dname
Hello, syzbot found the following crash on: HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11653ac3e0 kernel config: https://syzkaller.appspot.com/x/.config?x=9833e26bab355358 dashboard link: https://syzkaller.appspot.com/bug?extid=3643a18836bce555bff6 compiler: gcc (GCC) 9.0.0 20181231 (experimental) userspace arch: i386 Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in dmabuffs_dname+0x4f4/0x560 drivers/dma-buf/dma-buf.c:48 Read of size 8 at addr 8880a6b390e8 by task syz-executor.1/2394 CPU: 1 PID: 2394 Comm: syz-executor.1 Not tainted 5.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:641 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 dmabuffs_dname+0x4f4/0x560 drivers/dma-buf/dma-buf.c:48 tomoyo_realpath_from_path+0x165/0x660 security/tomoyo/realpath.c:259 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_check_open_permission+0x2a3/0x3e0 security/tomoyo/file.c:771 tomoyo_file_open security/tomoyo/tomoyo.c:319 [inline] tomoyo_file_open+0xa9/0xd0 security/tomoyo/tomoyo.c:314 security_file_open+0x71/0x300 security/security.c:1529 do_dentry_open+0x37a/0x1380 fs/open.c:784 vfs_open+0xa0/0xd0 fs/open.c:914 do_last fs/namei.c:3490 [inline] path_openat+0x12ee/0x3490 fs/namei.c:3607 do_filp_open+0x192/0x260 fs/namei.c:3637 do_sys_openat2+0x5eb/0x7e0 fs/open.c:1149 do_sys_open+0xf2/0x180 fs/open.c:1165 __do_compat_sys_open fs/open.c:1212 [inline] __se_compat_sys_open fs/open.c:1210 [inline] __ia32_compat_sys_open+0x79/0xb0 fs/open.c:1210 do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 RIP: 0023:0xf7fd8e39 Code: 1d 00 00 00 89 d3 5b 5e 5d c3 8b 04 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:f5db2014 EFLAGS: 0296 ORIG_RAX: 0005 RAX: ffda RBX: f5db204c RCX: RDX: RSI: 0c09 RDI: f5db204c RBP: f5db2168 R08: R09: R10: R11: R12: R13: R14: R15: Allocated by task 2388: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc mm/kasan/common.c:515 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:488 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 __do_kmalloc mm/slab.c:3656 [inline] __kmalloc+0x163/0x770 mm/slab.c:3665 kmalloc include/linux/slab.h:560 [inline] kzalloc include/linux/slab.h:669 [inline] dma_buf_export+0x24d/0xa80 drivers/dma-buf/dma-buf.c:533 ion_alloc drivers/staging/android/ion/ion.c:386 [inline] ion_ioctl+0x5a9/0xd20 drivers/staging/android/ion/ion.c:495 compat_ptr_ioctl+0x6e/0xa0 fs/ioctl.c:804 __do_compat_sys_ioctl fs/ioctl.c:857 [inline] __se_compat_sys_ioctl fs/ioctl.c:808 [inline] __ia32_compat_sys_ioctl+0x245/0x2c0 fs/ioctl.c:808 do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 Freed by task 2380: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10a/0x2c0 mm/slab.c:3757 dma_buf_release+0x343/0x420 drivers/dma-buf/dma-buf.c:111 __fput+0x2ff/0x890 fs/file_table.c:280 fput+0x16/0x20 fs/file_table.c:313 task_work_run+0x145/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:164 prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline] syscall_return_slowpath arch/x86/entry/common.c:278 [inline] do_syscall_32_irqs_on arch/x86/entry/common.c:352 [inline] do_fast_syscall_32+0xbbd/0xe16 arch/x86/entry/common.c:408 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 The buggy
Re: [PATCH v11 3/5] soc: mediatek: Move mt8173 MMSYS to platform driver
Hi Stephen,
On 5/3/20 22:01, Stephen Boyd wrote:
> Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
>> From: Matthias Brugger
>>
>> There is no strong reason for this to use CLK_OF_DECLARE instead of
>> being a platform driver.
>
> Cool.
>
>> Plus, this driver provides clocks but also
>> a shared register space for the mediatek-drm and the mediatek-mdp
>> driver. So move to drivers/soc/mediatek as a platform driver.
>>
>> Signed-off-by: Matthias Brugger
>> Signed-off-by: Enric Balletbo i Serra
>> Reviewed-by: CK Hu
>> ---
>>
>> Changes in v11: None
>> Changes in v10:
>> - Renamed to be generic mtk-mmsys
>> - Add driver data support to be able to support diferent SoCs
>>
>> Changes in v9:
>> - Move mmsys to drivers/soc/mediatek (CK)
>>
>> Changes in v8:
>> - Be a builtin_platform_driver like other mediatek mmsys drivers.
>>
>> Changes in v7:
>> - Free clk_data->clks as well
>> - Get rid of private data structure
>>
>> drivers/clk/mediatek/clk-mt8173.c | 104
>> drivers/soc/mediatek/Kconfig | 7 ++
>> drivers/soc/mediatek/Makefile | 1 +
>> drivers/soc/mediatek/mtk-mmsys.c | 154 ++
>
> Can you generate with -M so that we can see what has actually changed?
>
Sure, sorry about that.
>> 4 files changed, 162 insertions(+), 104 deletions(-)
>> create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
>>
>> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
>> index 2114b563478c..7a156944d50e 100644
>> --- a/drivers/soc/mediatek/Kconfig
>> +++ b/drivers/soc/mediatek/Kconfig
>> @@ -44,4 +44,11 @@ config MTK_SCPSYS
>> Say yes here to add support for the MediaTek SCPSYS power domain
>> driver.
>>
>> +config MTK_MMSYS
>> + bool "MediaTek MMSYS Support"
>> + depends on COMMON_CLK_MT8173
>
> Does it need some default so that defconfig updates don't break things?
>
Right.
>> + help
>> + Say yes here to add support for the MediaTek Multimedia
>> + Subsystem (MMSYS).
>> +
>> endmenu
>> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
>> index b01733074ad6..01f9f873634a 100644
>> --- a/drivers/soc/mediatek/Makefile
>> +++ b/drivers/soc/mediatek/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
>> obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
>> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
>> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
>> +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
>> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
>> b/drivers/soc/mediatek/mtk-mmsys.c
>> new file mode 100644
>> index ..473cdf732fb5
>> --- /dev/null
>> +++ b/drivers/soc/mediatek/mtk-mmsys.c
>> @@ -0,0 +1,154 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2014 MediaTek Inc.
>> + * Author: James Liao
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include "../../clk/mediatek/clk-gate.h"
>> +#include "../../clk/mediatek/clk-mtk.h"
>
> Why not use include/linux/clk/?
>
I can move these files to include, this will impact a lot more of drivers but,
yes, I think is the right way.
> But I also don't understand why the clk driver is moved outside of
> drivers/clk/ into drivers/soc/. Commit text saying that it has shared
> registers doesn't mean it can't still keep the clk driver part in the
> drivers/clk/ area.
>
Actually moving this to the soc directory has been requested by CK (mediatek) as
a change in v8. You can see the discussion in [1]
Thanks,
Enric
[1] https://patchwork.kernel.org/cover/11394709/
>> +
>> +#include
>> +
>> +static const struct mtk_gate_regs mm0_cg_regs = {
>> + .set_ofs = 0x0104,
>> + .clr_ofs = 0x0108,
>> + .sta_ofs = 0x0100,
>> +};
>> +
>> +static const struct mtk_gate_regs mm1_cg_regs = {
>> + .set_ofs = 0x0114,
>> + .clr_ofs = 0x0118,
>> + .sta_ofs = 0x0110,
>> +};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] dt-bindings: display: add visionox rm69299 panel variant
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob Herring).
Changes in v3:
- Changing txt file into yaml
Changes in v4:
- Updating license identifier.
- Moving yaml file inside panel directory.
- Removing pinctrl entries.
- Adding documentation for reset-gpios.
.../display/panel/visionox,rm69299.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
new file mode 100644
index ..93cae431207c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox model RM69299 Panels Device Tree Bindings.
+
+maintainers:
+ - Harigovindan P
+
+description: |
+ This binding is for display panels using a Visionox RM692999 panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+patternProperties:
+ "^(panel|panel-dsi)@[0-9]$":
+type: object
+properties:
+ compatible:
+const: visionox,rm69299-1080p-display
+
+ reg:
+maxItems: 1
+
+ vdda-supply:
+description:
+ Phandle of the regulator that provides the vdda supply voltage.
+
+ vdd3p3-supply:
+description:
+ Phandle of the regulator that provides the vdd3p3 supply voltage.
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+properties:
+ port@0:
+type: object
+description:
+ DSI input port node.
+
+ reset-gpios:
+description:
+ a GPIO spec for the reset pin.
+
+required:
+ - compatible
+ - reg
+ - vdda-supply
+ - vdd3p3-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+- |
+dsi@ae94000 {
+panel@0 {
+compatible = "visionox,rm69299-1080p-display";
+
+vdda-supply = <&src_pp1800_l8c>;
+vdd3p3-supply = <&src_pp2800_l18a>;
+
+reset-gpios = <&pm6150l_gpio 3 0>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+panel0_in: endpoint {
+remote-endpoint = <&dsi0_out>;
+};
+};
+};
+};
+};
+...
+
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: vm: Clean up documentation
Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/drm_vm.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 64619fe90046..aa88911bbc06 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -102,7 +102,7 @@ static pgprot_t drm_dma_prot(uint32_t map_type, struct vm_area_struct *vma) return tmp; } -/** +/* * \c fault method for AGP virtual memory. * * \param vma virtual memory area. @@ -192,7 +192,7 @@ static vm_fault_t drm_vm_fault(struct vm_fault *vmf) } #endif -/** +/* * \c nopage method for shared virtual memory. * * \param vma virtual memory area. @@ -225,7 +225,7 @@ static vm_fault_t drm_vm_shm_fault(struct vm_fault *vmf) return 0; } -/** +/* * \c close method for shared virtual memory. * * \param vma virtual memory area. @@ -294,7 +294,7 @@ static void drm_vm_shm_close(struct vm_area_struct *vma) mutex_unlock(&dev->struct_mutex); } -/** +/* * \c fault method for DMA virtual memory. * * \param address access address. @@ -329,7 +329,7 @@ static vm_fault_t drm_vm_dma_fault(struct vm_fault *vmf) return 0; } -/** +/* * \c fault method for scatter-gather virtual memory. * * \param address access address. @@ -435,7 +435,7 @@ static void drm_vm_close_locked(struct drm_device *dev, } } -/** +/* * \c close method for all virtual memory types. * * \param vma virtual memory area. @@ -453,7 +453,7 @@ static void drm_vm_close(struct vm_area_struct *vma) mutex_unlock(&dev->struct_mutex); } -/** +/* * mmap DMA memory. * * \param file_priv DRM file private. @@ -513,7 +513,7 @@ static resource_size_t drm_core_get_reg_ofs(struct drm_device *dev) #endif } -/** +/* * mmap DMA memory. * * \param file_priv DRM file private. -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] dt-bindings: display: rockchip: convert rockchip vop bindings to yaml
Current dts files with 'vop' nodes are manually verified.
In order to automate this process rockchip-vop.txt
has to be converted to yaml. Also included are new
properties needed for the latest Rockchip Socs.
Added properties:
assigned-clocks
assigned-clock-rates
power-domains
rockchip,grf
Signed-off-by: Johan Jonker
---
.../bindings/display/rockchip/rockchip-vop.txt | 74 ---
.../bindings/display/rockchip/rockchip-vop.yaml| 141 +
2 files changed, 141 insertions(+), 74 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
deleted file mode 100644
index 8b3a5f514..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-device-tree bindings for rockchip soc display controller (vop)
-
-VOP (Visual Output Processor) is the Display Controller for the Rockchip
-series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
-
-Required properties:
-- compatible: value should be one of the following
- "rockchip,rk3036-vop";
- "rockchip,rk3126-vop";
- "rockchip,px30-vop-lit";
- "rockchip,px30-vop-big";
- "rockchip,rk3066-vop";
- "rockchip,rk3188-vop";
- "rockchip,rk3288-vop";
- "rockchip,rk3368-vop";
- "rockchip,rk3366-vop";
- "rockchip,rk3399-vop-big";
- "rockchip,rk3399-vop-lit";
- "rockchip,rk3228-vop";
- "rockchip,rk3328-vop";
-
-- reg: Must contain one entry corresponding to the base address and length
- of the register space. Can optionally contain a second entry
- corresponding to the CRTC gamma LUT address.
-
-- interrupts: should contain a list of all VOP IP block interrupts in the
-order: VSYNC, LCD_SYSTEM. The interrupt specifier
-format depends on the interrupt controller used.
-
-- clocks: must include clock specifiers corresponding to entries in the
- clock-names property.
-
-- clock-names: Must contain
- aclk_vop: for ddr buffer transfer.
- hclk_vop: for ahb bus to R/W the phy regs.
- dclk_vop: pixel clock.
-
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - axi
- - ahb
- - dclk
-
-- iommus: required a iommu node
-
-- port: A port node with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-SoC specific DT entry:
- vopb: vopb@ff93 {
- compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
- interrupts = ;
- clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
- clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
- resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
- reset-names = "axi", "ahb", "dclk";
- iommus = <&vopb_mmu>;
- vopb_out: port {
- #address-cells = <1>;
- #size-cells = <0>;
- vopb_out_edp: endpoint@0 {
- reg = <0>;
- remote-endpoint=<&edp_in_vopb>;
- };
- vopb_out_hdmi: endpoint@1 {
- reg = <1>;
- remote-endpoint=<&hdmi_in_vopb>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
new file mode 100644
index 0..93ccd32aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip soc display controller (VOP)
+
+description:
+ VOP (Visual Output Processor) is the Display Controller for the Rockchip
+ series of SoCs which transfers the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+oneOf:
+ - const: rockchip,px30-vop-big
+ - const: rockchip,px30-vop-lit
+ - const: rockchip,rk3036-vop
+ - const: rockchip,rk3066-vop
+ - const:
Re: [PATCH] drm: komeda: Make rt_pm_ops dependent on CONFIG_PM
Hi Liviu,
On 3/5/20 6:42 PM, Liviu Dudau wrote:
> On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote:
>> komeda_rt_pm_suspend() and komeda_rt_pm_resume() are compiled only when
>> CONFIG_PM is enabled. Having it disabled triggers the following warning
>> at compile time:
>>
>> linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12:
>> warning: ‘komeda_rt_pm_resume’ defined but not used [-Wunused-function]
>> static int komeda_rt_pm_resume(struct device *dev)
>> ^~~
>> linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:149:12:
>> warning: ‘komeda_rt_pm_suspend’ defined but not used [-Wunused-function]
>> static int komeda_rt_pm_suspend(struct device *dev)
>>
>> Make komeda_rt_pm_suspend() and komeda_rt_pm_resume() dependent on
>> CONFIG_PM to address the issue.
>>
>> Cc: "James (Qian) Wang"
>> Cc: Liviu Dudau
>> Cc: Mihail Atanassov
>> Cc: Brian Starkey
>> Cc: David Airlie
>> Cc: Daniel Vetter
>> Signed-off-by: Vincenzo Frascino
>
> Acked-by: Liviu Dudau
>
> Thanks for the patch, I will push it into drm-misc-fixes tomorrow.
>
Thank you!
> Best regards,
> Liviu
>
>> ---
>> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
>> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
>> index ea5cd1e17304..dd3ae3d88687 100644
>> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
>> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
>> @@ -146,6 +146,7 @@ static const struct of_device_id komeda_of_match[] = {
>>
>> MODULE_DEVICE_TABLE(of, komeda_of_match);
>>
>> +#ifdef CONFIG_PM
>> static int komeda_rt_pm_suspend(struct device *dev)
>> {
>> struct komeda_drv *mdrv = dev_get_drvdata(dev);
>> @@ -159,6 +160,7 @@ static int komeda_rt_pm_resume(struct device *dev)
>>
>> return komeda_dev_resume(mdrv->mdev);
>> }
>> +#endif /* CONFIG_PM */
>>
>> static int __maybe_unused komeda_pm_suspend(struct device *dev)
>> {
>> --
>> 2.25.1
>>
>
--
Regards,
Vincenzo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道： > Hi Ondrej, > > On 5/3/20 20:35, Ondřej Jirman wrote: > > Hi, > > > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: > > > On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > > > wrote: > > > > Hi Vasily, > > > > > > CC: Icenowy and Ondrej > > > > Would you mind to check which firmware version is running the > > > > anx7688 in > > > > PinePhone, I think should be easy to check with i2c-tools. > > > > > > Icenowy, Ondrej, can you guys please check anx7688 firmware > > > version? > > > > i2cget 0 0x28 0x00 w > > 0x > > > > i2cget 0 0x28 0x02 w > > 0x7688 > > > > i2cget 0 0x28 0x80 w > > 0x > > > > Can you check the value for 0x81 too? root@ice-pinephone [ ~ ] # i2cdump 0 0x28 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x28, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: aa aa 88 76 ac 00 00 00 00 00 00 00 00 00 05 05???v?.?? 10: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000... 20: 00 00 00 00 00 00 00 00 00 00 00 24 f2 e4 ff 00...$??.. 30: 06 40 00 04 94 11 20 ff ff 03 00 bf ff ff 10 01?@.??? ..?.?..?? 40: 72 a4 00 09 00 08 05 84 15 40 17 00 00 0a 00 e0r?.?.@?..?.? 50: 00 00 00 0a 10 00 e0 df ff ff 00 00 00 10 71 00...??.??.?q. 60: 10 10 04 29 2d 21 10 01 09 13 00 03 e8 13 88 00???)-!.. 70: 00 19 18 83 16 5c 11 00 ff 00 00 0d 04 38 42 07.\???8B? 80: 00 00 00 00 00 74 1b 19 44 08 75 00 00 00 00 00.t??D?u. 90: 01 02 00 00 00 00 03 00 ff 30 00 59 01 00 00 00???..0.Y?... a0: 00 ff fe ff ff 00 00 00 00 00 00 00 00 00 00 02..?? b0: 00 00 00 00 00 00 40 00 28 00 00 00 00 44 08 00..@.(D?. c0: 00 00 00 00 80 00 10 01 0a 10 18 00 00 fd 00 00?.?..?.. d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 50 10 08 50 00 02 00 70 00 00 30 10 0b 02 1c 01P??P.?.p..0? f0: 00 0b 07 00 94 11 7f 00 00 00 00 00 00 01 0e ff.??.???..??. root@ice-pinephone [ ~ ] # i2cdump 0 0x2c No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x2c, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 29 1f 88 76 00 ac 11 00 11 20 10 10 00 00 00 00)??v.??.? ?? 10: 03 00 ff 8f ff 7f 00 00 00 00 05 00 10 0a 0c 00?..?.??.???. 20: 00 00 00 00 99 06 c0 00 00 00 00 00 00 00 02 00???...?. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 80: 01 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00?%.. 90: 0f 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00??.. a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Thanks, > Enric > > > > regards, > > o. > > > > > > Thanks in advance, > > > > Enric > > > > > > > > [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
Hi Ondrej, On 5/3/20 20:35, Ondřej Jirman wrote: > Hi, > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: >> On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra >> wrote: >>> >>> Hi Vasily, >> >> CC: Icenowy and Ondrej >>> >>> Would you mind to check which firmware version is running the anx7688 in >>> PinePhone, I think should be easy to check with i2c-tools. >> >> Icenowy, Ondrej, can you guys please check anx7688 firmware version? > > i2cget 0 0x28 0x00 w > 0x > > i2cget 0 0x28 0x02 w > 0x7688 > > i2cget 0 0x28 0x80 w > 0x > Can you check the value for 0x81 too? Thanks, Enric > regards, > o. > >>> Thanks in advance, >>> Enric >>> >>> [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Fri, Mar 06, 2020 at 08:11:07PM +0800, Nicolas Boichat wrote: > On Fri, Mar 6, 2020 at 8:07 PM Ondřej Jirman wrote: > > What about the values at 0x2c? i2cdump 0 0x28 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: aa aa 88 76 ac 00 00 00 00 00 00 00 00 80 05 05???v???? 10: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000... 20: 00 00 00 00 00 00 00 00 00 00 00 34 f2 e4 ff 00...4??.. 30: 04 40 00 04 94 11 20 ff ff 03 00 ff ff ff 00 01?@.??? ..?.? 40: 78 a4 00 09 00 08 05 84 10 60 17 00 00 0a 00 b0x?.?.`?..?.? 50: 00 00 00 0a 00 00 e0 df ff ff 00 00 00 10 71 00...?..??.?q. 60: 10 10 04 29 2d 21 10 01 09 03 00 03 e8 13 88 00???)-!.. 70: 00 19 18 83 06 5a 11 00 ff 00 00 0d 04 38 42 07.Z???8B? 80: 00 00 00 00 00 74 1b 19 40 08 75 00 00 00 00 00.t??@?u. 90: 00 00 00 00 00 00 03 00 ff 30 00 59 01 00 00 00..?..0.Y?... a0: 00 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 0a 10 18 00 00 ff 00 00???. d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 50 10 08 50 00 02 00 70 00 00 30 10 11 02 1c 01P??P.?.p..0? f0: 00 11 07 00 94 11 7f 00 00 00 00 00 00 01 0e ff.??.???..??. i2cdump 0 0x2c 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 29 1f 88 76 00 ac 11 00 11 20 10 10 00 00 00 00)??v.??.? ?? 10: 03 00 ff 8f ff 7f 00 00 00 00 0a 00 10 11 0c 00?..?.??.???. 20: 00 00 00 00 99 06 c0 00 00 00 00 00 00 00 02 00???...?. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: b4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 80: 01 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00?%.. 90: 0f 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00??.. a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 regards, o. > > Thanks, ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
Hi Icenowy, On 5/3/20 19:35, Icenowy Zheng wrote: > > > 于 2020年3月6日 GMT+08:00 上午2:29:33, Vasily Khoruzhick 写到: >> On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra >> wrote: >>> >>> Hi Vasily, >> >> CC: Icenowy and Ondrej >>> >>> Would you mind to check which firmware version is running the anx7688 >> in >>> PinePhone, I think should be easy to check with i2c-tools. >> >> Icenowy, Ondrej, can you guys please check anx7688 firmware version? > > At 0x2c, 0x80 is 0x01, 0x81 is 0x25 > > 01.25, right? > Yes, thanks. >> >>> Thanks in advance, >>> Enric >>> >>> [snip] > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/panel: add support for rm69299 visionox panel driver
Add support for Visionox panel driver.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Dropping redundant space in Kconfig(Sam Ravnborg).
- Changing structure for include files(Sam Ravnborg).
- Removing backlight related code and functions(Sam Ravnborg).
- Removing repeated printing of error message(Sam Ravnborg).
- Adding drm_connector as an argument for get_modes function.
Changes in v3:
- Adding arguments for drm_panel_init to support against mainline.
Changes in v4:
- Removing error messages from regulator_set_load.
- Removing dev struct entry.
- Removing checks.
- Dropping empty comment lines.
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-visionox-rm69299.c| 322 ++
3 files changed, 331 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..7b696f304a99 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -389,6 +389,14 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_VISIONOX_RM69299
+ tristate "Visionox RM69299"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Visionox
+ RM69299 DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..9f11d067a6b2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -41,4 +41,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
new file mode 100644
index ..eb15dca15398
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+struct rm69299_config {
+ unsigned long width_mm;
+ unsigned long height_mm;
+ const char *panel_name;
+ u32 num_on_cmds;
+ const struct drm_display_mode *dm;
+};
+
+struct visionox_rm69299 {
+ struct drm_panel panel;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct gpio_desc *reset_gpio;
+
+ struct mipi_dsi_device *dsi;
+ const struct rm69299_config *config;
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct visionox_rm69299 *panel_to_ctx(struct drm_panel *panel)
+{
+ return container_of(panel, struct visionox_rm69299, panel);
+}
+
+static int visionox_35597_power_on(struct visionox_rm69299 *ctx)
+{
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ if (ret < 0)
+ return ret;
+
+ /*
+* Reset sequence of visionox panel requires the panel to be
+* out of reset for 10ms, followed by being held in reset
+* for 10ms and then out again
+*/
+ gpiod_set_value(ctx->reset_gpio, 1);
+ usleep_range(1, 2);
+ gpiod_set_value(ctx->reset_gpio, 0);
+ usleep_range(1, 2);
+ gpiod_set_value(ctx->reset_gpio, 1);
+ usleep_range(1, 2);
+
+ return 0;
+}
+
+static int visionox_rm69299_power_off(struct visionox_rm69299 *ctx)
+{
+ gpiod_set_value(ctx->reset_gpio, 0);
+
+ return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+}
+
+static int visionox_rm69299_unprepare(struct drm_panel *panel)
+{
+ struct visionox_rm69299 *ctx = panel_to_ctx(panel);
+ int ret;
+
+ ctx->dsi->mode_flags = 0;
+
+ ret = mipi_dsi_dcs_write(ctx->dsi, MIPI_DCS_SET_DISPLAY_OFF, NULL, 0);
+ if (ret < 0)
+ DRM_DEV_ERROR(ctx->panel.dev, "set_display_off cmd failed ret =
%d\n", ret);
+
+ /* 120ms delay required here as per DCS spec */
+ msleep(120);
+
+ ret = mipi_dsi_dcs_write(ctx->dsi, MIPI_DCS_ENTER_SLEEP_MODE, NULL, 0);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->panel.dev,
+ "enter_sleep cmd failed ret = %d\n", ret);
+ }
+
+
[v1] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings
MSM Mobile Display Subsytem(MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for the device tree bindings for the same. Signed-off-by: Krishna Manikandan --- .../bindings/display/msm/dpu-sc7180.yaml | 269 +++ .../bindings/display/msm/dpu-sdm845.yaml | 265 +++ .../bindings/display/msm/dsi-sc7180.yaml | 369 + .../bindings/display/msm/dsi-sdm845.yaml | 369 + 4 files changed, 1272 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-sc7180.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-sdm845.yaml diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml new file mode 100644 index 000..3d1d9b8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml @@ -0,0 +1,269 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Description of Qualcomm Display Dpu dt properties. + +maintainers: + - Krishna Manikandan + +description: | + Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SC7180 target. + +properties: + "mdss": + type: object + description: | + Node containing MDSS that encapsulated sub-blocks like DPU, DSI and DP + interfaces. + + properties: + compatible: +items: + - const: qcom,sc7180-mdss + reg: +description: | + Physical base address and length of controller's registers. + + reg-names: +description: | + Names for different register regions defined above. The required region + is mentioned below. +items: + - const: mdss + + power-domains: +description: | + A power domain consumer specifier according to + Documentation/devicetree/bindings/power/power_domain.txt. + + clocks: +description: | + List of clock specifiers for clocks needed by the device. + + clock-names: +description: | + Device clock names in the same order as mentioned in clocks property. + The required clocks are mentioned below. +items: + - const: iface + - const: bus + - const: ahb + - const: core + + interrupts: +description: | + Interrupt signal from MDSS. + + interrupt-controller: +description: | + Identifies the node as an interrupt controller. + + "#interrupt-cells": +description: | + Specifies the number of cells needed to encode an interrupt source. +const: 1 + + iommus: +description: | + Phandle of iommu device node. + + "#address-cells": +description: | + Indicate how many cells (32 bits values) are needed to form the base + address part in the reg property. + + "#size-cells": +description: | + Indicate how many cells (32 bits values) are needed to specify the size + part in the reg property. + + ranges: +description: | + Parent bus address space is the same as the child bus address space. + + interconnects : +description: | + Interconnect path specifier for MDSS according to + Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be + 2 paths corresponding to 2 AXI ports. + + interconnect-names: +description: | + MDSS will have 2 port names to differentiate between the + 2 interconnect paths defined with interconnect specifier. + + properties: +description: | + Optional properties for MDSS. + + assigned-clocks: + description: | + List of clock specifiers for clocks needing rate assignment. + + assigned-clock-rates: + description: | + List of clock frequencies sorted in the same order as the assigned-clocks + property. + + "mdp": +type: object +description: | + Node containing the properties of DPU. +properties: + compatible: + items: + - const: qcom,sc7180-dpu + + reg: + description: | + Physical base address and length of controller's registers. + + reg-names: + description: | + Register region names. The following regions are required. + items: +- const: mdp +- const: vbif + + clocks: + description: | + List of clock specifiers for clocks needed by the device. + + clock-names: + description: | + Device clock names, must be in same order as clocks property. + The following clocks are required. "bus" is an optional property + in sc7180 due to architecture change. +
Re: [PATCH] drm: Make drm_pci_agp_init legacy
Hi Chris.
On Sat, Mar 07, 2020 at 09:37:02AM +, Chris Wilson wrote:
> Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its
> only caller.
>
> Signed-off-by: Chris Wilson
I dunno this code - but patch is obviously correct.
This diff is a bit weird as it shows that another function is moved.
But it makes sense looking at drm_pci.c
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_pci.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 5218475ad7e7..81aa21561982 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -166,6 +166,18 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
> return drm_pci_irq_by_busid(dev, p);
> }
>
> +void drm_pci_agp_destroy(struct drm_device *dev)
> +{
> + if (dev->agp) {
> + arch_phys_wc_del(dev->agp->agp_mtrr);
> + drm_legacy_agp_clear(dev);
> + kfree(dev->agp);
> + dev->agp = NULL;
> + }
> +}
> +
> +#ifdef CONFIG_DRM_LEGACY
> +
> static void drm_pci_agp_init(struct drm_device *dev)
> {
> if (drm_core_check_feature(dev, DRIVER_USE_AGP)) {
> @@ -180,18 +192,6 @@ static void drm_pci_agp_init(struct drm_device *dev)
> }
> }
>
> -void drm_pci_agp_destroy(struct drm_device *dev)
> -{
> - if (dev->agp) {
> - arch_phys_wc_del(dev->agp->agp_mtrr);
> - drm_legacy_agp_clear(dev);
> - kfree(dev->agp);
> - dev->agp = NULL;
> - }
> -}
> -
> -#ifdef CONFIG_DRM_LEGACY
> -
> static int drm_get_pci_dev(struct pci_dev *pdev,
> const struct pci_device_id *ent,
> struct drm_driver *driver)
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 51/51] drm: Add docs for managed resources
Hi Daniel. On Mon, Mar 02, 2020 at 11:26:31PM +0100, Daniel Vetter wrote: > All collected together to provide a consistent story in one patch, > instead of the somewhat bumpy refactor-evolution leading to this. > > Also some thoughts on what the next steps could be: > > - Create a macro called devm_drm_dev_alloc() which essentially wraps > the kzalloc(); devm_drm_dev_init(); drmm_add_final_kfree() combo. > Needs to be a macro since we'll have to do some typeof trickery and > casting to make this fully generic for all drivers that embed struct > drm_device into their own thing. > > - A lot of the simple drivers now have essentially just > drm_dev_unplug(); drm_atomic_helper_shutdown(); as their > $bus_driver->remove hook. We could create a devm_mode_config_reset > which sets drm_atomic_helper_shutdown as it's cleanup action, and a > devm_drm_dev_register with drm_dev_unplug as it's cleanup action, > and simple drivers wouldn't have a need for a ->remove function at > all, and we could delete them. > > - For more complicated drivers we need drmm_ versions of a _lot_ more > things. All the userspace visible objects (crtc, plane, encoder, > crtc), anything else hanging of those (maybe a drmm_get_edid, at > least for panels and other built-in stuff). When this patch set is landed and the dut have setteled it would be good with a detailed todo entry including the above. But let's land this first. > > Also some more thoughts on why we're not reusing devm_ with maybe a > fake struct device embedded into the drm_device (we can't use the > kdev, since that's in each drm_minor). > > - Code review gets extremely tricky, since every time you see a devm_ > you need to carefully check whether the fake device (with the > drm_device lifetim) or the real device (with the lifetim of the > underlying physical device and driver binding) are used. That's not > going to help at all, and we have enormous amounts of drivers who > use devm_ where they really shouldn't. Having different types makes > sure the compiler type checks this for us and ensures correctness. > > - The set of functions are very much non-overlapping. E.g. > devm_ioremap makes total sense, drmm_ioremap has the wrong lifetime, > since hw resources need to be cleaned out at driver unbind and wont > outlive that like a drm_device. Similar, but other way round for > drmm_connector_init (which is the only correct version, devm_ for > drm_connector is just buggy). Simply not having the wrong version > again prevents bugs. > > Finally I guess this opens a huge todo for all the drivers. I'm > semi-tempted to do a tree-wide s/devm_kzalloc/drmm_kzalloc/ since most > likely that'll fix an enormous amount of bugs and most likely not > cause any issues at all (aside from maybe holding onto memory slightly > too long). > > v2: > - Doc improvements from Laurent. > - Also add kerneldoc for the new drmm_add_action_or_reset. > > Cc: Sam Ravnborg > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Laurent Pinchart > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by: Daniel Vetter Looks good - nice overview and good function descriptions. Reviewed-by: Sam Ravnborg > --- > Documentation/gpu/drm-internals.rst | 6 +++ > drivers/gpu/drm/drm_drv.c | 18 +++-- > drivers/gpu/drm/drm_managed.c | 61 + > include/drm/drm_drv.h | 4 ++ > include/drm/drm_managed.h | 58 +++ > 5 files changed, 144 insertions(+), 3 deletions(-) > > diff --git a/Documentation/gpu/drm-internals.rst > b/Documentation/gpu/drm-internals.rst > index a6b6145fda78..12272b168580 100644 > --- a/Documentation/gpu/drm-internals.rst > +++ b/Documentation/gpu/drm-internals.rst > @@ -138,6 +138,12 @@ Managed Resources > .. kernel-doc:: drivers/gpu/drm/drm_managed.c > :doc: managed resources > > +.. kernel-doc:: drivers/gpu/drm/drm_managed.c > + :export: > + > +.. kernel-doc:: include/drm/drm_managed.h > + :internal: > + > Bus-specific Device Registration and PCI Support > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index a82702d0c2fb..cd172080649c 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -260,9 +260,15 @@ void drm_minor_release(struct drm_minor *minor) > * any other resources allocated at device initialization and drop the > driver's > * reference to &drm_device using drm_dev_put(). > * > - * Note that the lifetime rules for &drm_device instance has still a lot of > - * historical baggage. Hence use the reference counting provided by > - * drm_dev_get() and drm_dev_put() only carefully. > + * Note that any allocation or resource which is visible to userspace must be > + * released only when the final drm_dev_put() is called, and not when the > + * driver is unbound from the underlying physical s
[PATCH] drm: Make drm_pci_agp_init legacy
Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its
only caller.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_pci.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 5218475ad7e7..81aa21561982 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -166,6 +166,18 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
return drm_pci_irq_by_busid(dev, p);
}
+void drm_pci_agp_destroy(struct drm_device *dev)
+{
+ if (dev->agp) {
+ arch_phys_wc_del(dev->agp->agp_mtrr);
+ drm_legacy_agp_clear(dev);
+ kfree(dev->agp);
+ dev->agp = NULL;
+ }
+}
+
+#ifdef CONFIG_DRM_LEGACY
+
static void drm_pci_agp_init(struct drm_device *dev)
{
if (drm_core_check_feature(dev, DRIVER_USE_AGP)) {
@@ -180,18 +192,6 @@ static void drm_pci_agp_init(struct drm_device *dev)
}
}
-void drm_pci_agp_destroy(struct drm_device *dev)
-{
- if (dev->agp) {
- arch_phys_wc_del(dev->agp->agp_mtrr);
- drm_legacy_agp_clear(dev);
- kfree(dev->agp);
- dev->agp = NULL;
- }
-}
-
-#ifdef CONFIG_DRM_LEGACY
-
static int drm_get_pci_dev(struct pci_dev *pdev,
const struct pci_device_id *ent,
struct drm_driver *driver)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 46/51] drm/repaper: Drop explicit drm_mode_config_cleanup call
On Mon, Mar 02, 2020 at 11:26:26PM +0100, Daniel Vetter wrote:
> Allows us to drop the drm_driver.release callback.
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> v2: Explain why this cleanup is possible (Laurent).
>
> v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
> I also noticed that I've failed to add the error checking,
> __must_check caught that.
>
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: Laurent Pinchart
> Reviewed-by: Noralf Trønnes (v2)
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/tiny/repaper.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
> index 4741ff670ec9..862c3ee6055d 100644
> --- a/drivers/gpu/drm/tiny/repaper.c
> +++ b/drivers/gpu/drm/tiny/repaper.c
> @@ -909,13 +909,6 @@ static const struct drm_mode_config_funcs
> repaper_mode_config_funcs = {
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> -static void repaper_release(struct drm_device *drm)
> -{
> - DRM_DEBUG_DRIVER("\n");
> -
> - drm_mode_config_cleanup(drm);
> -}
> -
> static const uint32_t repaper_formats[] = {
> DRM_FORMAT_XRGB,
> };
> @@ -953,7 +946,6 @@ DEFINE_DRM_GEM_CMA_FOPS(repaper_fops);
> static struct drm_driver repaper_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &repaper_fops,
> - .release= repaper_release,
> DRM_GEM_CMA_VMAP_DRIVER_OPS,
> .name = "repaper",
> .desc = "Pervasive Displays RePaper e-ink panels",
> @@ -1023,7 +1015,9 @@ static int repaper_probe(struct spi_device *spi)
> }
> drmm_add_final_kfree(drm, epd);
>
> - drm_mode_config_init(drm);
> + ret = drmm_mode_config_init(drm);
> + if (ret)
> + return ret;
> drm->mode_config.funcs = &repaper_mode_config_funcs;
>
> epd->spi = spi;
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 40/51] drm/mtk: Drop explicit drm_mode_config_cleanup call
On Mon, Mar 02, 2020 at 11:26:20PM +0100, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> Aside: Another driver with a bit much devm_kzalloc, which should
> probably use drmm_kzalloc instead ...
>
> v2: Explain why this cleanup is possible (Laurent).
>
> v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
>
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 0563c681..2eaa9080d250 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -162,7 +162,9 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> }
> private->mutex_dev = &pdev->dev;
>
> - drm_mode_config_init(drm);
> + ret = drmm_mode_config_init(drm);
> + if (ret)
> + return ret;
>
> drm->mode_config.min_width = 64;
> drm->mode_config.min_height = 64;
> @@ -179,7 +181,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>
> ret = component_bind_all(drm->dev, drm);
> if (ret)
> - goto err_config_cleanup;
> + return ret;
>
> /*
>* We currently support two fixed data streams, each optional,
> @@ -255,8 +257,6 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> dma_dev->dma_parms = NULL;
> err_component_unbind:
> component_unbind_all(drm->dev, drm);
> -err_config_cleanup:
> - drm_mode_config_cleanup(drm);
>
> return ret;
> }
> @@ -272,7 +272,6 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
> private->dma_dev->dma_parms = NULL;
>
> component_unbind_all(drm->dev, drm);
> - drm_mode_config_cleanup(drm);
> }
>
> static const struct file_operations mtk_drm_fops = {
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 38/51] drm/stm: Drop explicit drm_mode_config_cleanup call
On Mon, Mar 02, 2020 at 11:26:18PM +0100, Daniel Vetter wrote: > It's right above the drm_dev_put(). > > This is made possible by a preceeding patch which added a drmm_ > cleanup action to drm_mode_config_init(), hence all we need to do to > ensure that drm_mode_config_cleanup() is run on final drm_device > cleanup is check the new error code for _init(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... > > v2: Explain why this cleanup is possible (Laurent). > > v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) > > Cc: Sam Ravnborg > Cc: Thomas Zimmermann > Acked-by: Philippe Cornu > Cc: Laurent Pinchart > Signed-off-by: Daniel Vetter > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-arm-ker...@lists.infradead.org Acked-by: Sam Ravnborg > --- > drivers/gpu/drm/stm/drv.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c > index ea9fcbdc68b3..0f85dd86cafa 100644 > --- a/drivers/gpu/drm/stm/drv.c > +++ b/drivers/gpu/drm/stm/drv.c > @@ -88,7 +88,9 @@ static int drv_load(struct drm_device *ddev) > > ddev->dev_private = (void *)ldev; > > - drm_mode_config_init(ddev); > + ret = drmm_mode_config_init(ddev); > + if (ret) > + return ret; > > /* >* set max width and height as default value. > @@ -103,7 +105,7 @@ static int drv_load(struct drm_device *ddev) > > ret = ltdc_load(ddev); > if (ret) > - goto err; > + return ret; > > drm_mode_config_reset(ddev); > drm_kms_helper_poll_init(ddev); > @@ -111,9 +113,6 @@ static int drv_load(struct drm_device *ddev) > platform_set_drvdata(pdev, ddev); > > return 0; > -err: > - drm_mode_config_cleanup(ddev); > - return ret; > } > > static void drv_unload(struct drm_device *ddev) > @@ -122,7 +121,6 @@ static void drv_unload(struct drm_device *ddev) > > drm_kms_helper_poll_fini(ddev); > ltdc_unload(ddev); > - drm_mode_config_cleanup(ddev); > } > > static __maybe_unused int drv_suspend(struct device *dev) > -- > 2.24.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm: Remove drm dp mst destroy_connector callbacks
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
connector((drm_connector_unregister()/drm_connector_put())) except for
amdgpu_dm driver where some amdgpu_dm specific code in there.
This connector cleaning up is now being handled in the drm core so
driver destroy_connector callbacks are not needed (except for
amdgpu_dm) hence remove them.
Removal is done with below sementic patch:
@r1@
identifier func, E;
@@
struct drm_dp_mst_topology_cbs E = {
...,
-.destroy_connector = func
};
@delete depends on r1@
identifier r1.func;
@@
- static void func(...){...}
Signed-off-by: Pankaj Bharadiya
Suggested-by: Emil Velikov
Suggested-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 --
drivers/gpu/drm/nouveau/dispnv50/disp.c | 12
drivers/gpu/drm/radeon/radeon_dp_mst.c | 11 ---
3 files changed, 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index c6574a0a15b9..a47d14b0c140 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -719,18 +719,8 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return NULL;
}
-static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_connector *connector)
-{
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
connector->name);
- drm_connector_unregister(connector);
-
- drm_connector_put(connector);
-}
-
static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = intel_dp_add_mst_connector,
- .destroy_connector = intel_dp_destroy_mst_connector,
};
static struct intel_dp_mst_encoder *
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 4e3917073797..4d1c58468dbc 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1256,17 +1256,6 @@ nv50_mstm_prepare(struct nv50_mstm *mstm)
}
}
-static void
-nv50_mstm_destroy_connector(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_connector *connector)
-{
- struct nv50_mstc *mstc = nv50_mstc(connector);
-
- drm_connector_unregister(&mstc->connector);
-
- drm_connector_put(&mstc->connector);
-}
-
static struct drm_connector *
nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port, const char *path)
@@ -1285,7 +1274,6 @@ nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr
*mgr,
static const struct drm_dp_mst_topology_cbs
nv50_mstm = {
.add_connector = nv50_mstm_add_connector,
- .destroy_connector = nv50_mstm_destroy_connector,
};
void
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 795e2df773ae..008308780443 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -301,19 +301,8 @@ static struct drm_connector
*radeon_dp_add_mst_connector(struct drm_dp_mst_topol
return connector;
}
-static void radeon_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
- struct drm_connector *connector)
-{
- drm_connector_unregister(connector);
- drm_connector_cleanup(connector);
-
- kfree(connector);
- DRM_DEBUG_KMS("\n");
-}
-
static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = radeon_dp_add_mst_connector,
- .destroy_connector = radeon_dp_destroy_mst_connector,
};
static struct
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm: Add drm_dp_destroy_connector helper and use it
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
connector (drm_connector_unregister()/drm_connector_put()) except for
amdgpu_dm driver where some amdgpu_dm specific code in there which I
an not sure if it should stay or not.
Create and use a helper which calls driver's destroy_connector hook if
available otherwise does cleanup internally.
This is the step towards removing identical hooks from every driver.
Signed-off-by: Pankaj Bharadiya
Suggested-by: Emil Velikov
Suggested-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 53d10d6c91d9..8374cac74ccc 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4667,11 +4667,23 @@ static void drm_dp_tx_work(struct work_struct *work)
mutex_unlock(&mgr->qlock);
}
+static inline void drm_dp_destroy_connector(struct drm_dp_mst_port *port)
+{
+ if (!port->connector)
+ return;
+
+ if (port->mgr->cbs->destroy_connector) {
+ port->mgr->cbs->destroy_connector(port->mgr, port->connector);
+ } else {
+ drm_connector_unregister(port->connector);
+ drm_connector_put(port->connector);
+ }
+}
+
static inline void
drm_dp_delayed_destroy_port(struct drm_dp_mst_port *port)
{
- if (port->connector)
- port->mgr->cbs->destroy_connector(port->mgr, port->connector);
+ drm_dp_destroy_connector(port);
drm_dp_port_set_pdt(port, DP_PEER_DEVICE_NONE, port->mcs);
drm_dp_mst_put_port_malloc(port);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm: Register connector instead of calling register_connector callback
drm_dp_mst_topology_mgr_cbs.register_connector callbacks are literally identical amongst every driver and don't do anything other than calling drm_connector_register(). Hence call drm_connector_register() directly instead of a callback. This is the preparatory step for removing the drm_dp_mst_topology_mgr_cbs.register_connector callback hook. Signed-off-by: Pankaj Bharadiya Suggested-by: Emil Velikov Suggested-by: Lyude Paul --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 6c62ad8f4414..53d10d6c91d9 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2175,7 +2175,7 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch *mstb, drm_connector_set_tile_property(port->connector); } - mgr->cbs->register_connector(port->connector); + drm_connector_register(port->connector); return; error: -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/dp_mst: Remove register_connector callback
Now drm_dp_mst_topology_cbs.register_connector callback is not getting
used anymore hence remove it.
Signed-off-by: Pankaj Bharadiya
Suggested-by: Emil Velikov
Suggested-by: Lyude Paul
---
include/drm/drm_dp_mst_helper.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 5483f888712a..885ada3c15a5 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -479,7 +479,6 @@ struct drm_dp_mst_topology_mgr;
struct drm_dp_mst_topology_cbs {
/* create a connector for a port */
struct drm_connector *(*add_connector)(struct drm_dp_mst_topology_mgr
*mgr, struct drm_dp_mst_port *port, const char *path);
- void (*register_connector)(struct drm_connector *connector);
void (*destroy_connector)(struct drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector);
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: Remove dp mst register connector callbacks
drm_dp_mst_port_add_connector() directly calls the
drm_connector_register() now and
drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting
called anymore.
Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector
callbacks.
This is the preparatory step for removing the
drm_dp_mst_topology_mgr_cbs.register_connector callback hook.
The removal is done with below sementic patch:
@r1@
identifier func, E;
@@
struct drm_dp_mst_topology_cbs E = {
...,
-.register_connector = func
};
@delete depends on r1@
identifier r1.func;
@@
- static void func(...){...}
Signed-off-by: Pankaj Bharadiya
Suggested-by: Emil Velikov
Suggested-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 6 --
drivers/gpu/drm/i915/display/intel_dp_mst.c| 6 --
drivers/gpu/drm/nouveau/dispnv50/disp.c| 7 ---
drivers/gpu/drm/radeon/radeon_dp_mst.c | 6 --
4 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 00c8627eb60e..5ee2dc4597f0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -458,15 +458,9 @@ static void dm_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_connector_put(connector);
}
-static void dm_dp_mst_register_connector(struct drm_connector *connector)
-{
- drm_connector_register(connector);
-}
-
static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
.add_connector = dm_dp_add_mst_connector,
.destroy_connector = dm_dp_destroy_mst_connector,
- .register_connector = dm_dp_mst_register_connector
};
void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d53978ed3c12..c6574a0a15b9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -719,11 +719,6 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return NULL;
}
-static void intel_dp_register_mst_connector(struct drm_connector *connector)
-{
- drm_connector_register(connector);
-}
-
static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector)
{
@@ -735,7 +730,6 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = intel_dp_add_mst_connector,
- .register_connector = intel_dp_register_mst_connector,
.destroy_connector = intel_dp_destroy_mst_connector,
};
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 4e164ad8003f..4e3917073797 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1267,12 +1267,6 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_connector_put(&mstc->connector);
}
-static void
-nv50_mstm_register_connector(struct drm_connector *connector)
-{
- drm_connector_register(connector);
-}
-
static struct drm_connector *
nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port, const char *path)
@@ -1291,7 +1285,6 @@ nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr
*mgr,
static const struct drm_dp_mst_topology_cbs
nv50_mstm = {
.add_connector = nv50_mstm_add_connector,
- .register_connector = nv50_mstm_register_connector,
.destroy_connector = nv50_mstm_destroy_connector,
};
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 5a9fb0ad175a..795e2df773ae 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -301,11 +301,6 @@ static struct drm_connector
*radeon_dp_add_mst_connector(struct drm_dp_mst_topol
return connector;
}
-static void radeon_dp_register_mst_connector(struct drm_connector *connector)
-{
- drm_connector_register(connector);
-}
-
static void radeon_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_connector *connector)
{
@@ -318,7 +313,6 @@ static void radeon_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = radeon_dp_add_mst_connector,
- .register_connector = radeon_dp_register_mst_connector,
.destroy_connector = radeon_dp_destroy_mst_connector,
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://li
[PATCH 0/5] Cleanup drm_dp_mst_topology_cbs hooks
drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical amongst every driver and don't do anything other than calling drm_connector_register(). drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector((drm_connector_unregister()/drm_connector_put())) except for amdgpu_dm driver where some amdgpu_dm specific code in there. This series aims to cleaup these drm_dp_mst_topology_mgr_cbs hooks. Pankaj Bharadiya (5): drm: Register connector instead of calling register_connector callback drm: Remove dp mst register connector callbacks drm/dp_mst: Remove register_connector callback drm: Add drm_dp_destroy_connector helper and use it drm: Remove drm dp mst destroy_connector callbacks .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 -- drivers/gpu/drm/drm_dp_mst_topology.c | 18 +++--- drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 drivers/gpu/drm/nouveau/dispnv50/disp.c | 19 --- drivers/gpu/drm/radeon/radeon_dp_mst.c| 17 - include/drm/drm_dp_mst_helper.h | 1 - 6 files changed, 15 insertions(+), 62 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/51] drm/rockchip: Drop explicit drm_mode_config_cleanup call
On Mon, Mar 02, 2020 at 11:26:17PM +0100, Daniel Vetter wrote: > It's (almost, there's some iommu stuff without significance) right > above the drm_dev_put(). > > This is made possible by a preceeding patch which added a drmm_ > cleanup action to drm_mode_config_init(), hence all we need to do to > ensure that drm_mode_config_cleanup() is run on final drm_device > cleanup is check the new error code for _init(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... > > v2: Explain why this cleanup is possible (Laurent). > > v3: Jump out at the right label (Francesco) > > v4: Try again, kbuild caught that I didn't build test this properly > ... > > v5: Use drmm_mode_config_init() for more clarity (Sam, Thomas) > > Cc: Sam Ravnborg > Cc: Thomas Zimmermann > Cc: Francesco Lavra > Cc: Laurent Pinchart > Signed-off-by: Daniel Vetter > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org Acked-by: Sam Ravnborg > --- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 14 +- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > index 20ecb1508a22..0f3eb392fe39 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > @@ -135,14 +135,16 @@ static int rockchip_drm_bind(struct device *dev) > if (ret) > goto err_free; > > - drm_mode_config_init(drm_dev); > + ret = drmm_mode_config_init(drm_dev); > + if (ret) > + goto err_iommu_cleanup; > > rockchip_drm_mode_config_init(drm_dev); > > /* Try to bind all sub drivers. */ > ret = component_bind_all(dev, drm_dev); > if (ret) > - goto err_mode_config_cleanup; > + goto err_iommu_cleanup; > > ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc); > if (ret) > @@ -173,12 +175,9 @@ static int rockchip_drm_bind(struct device *dev) > rockchip_drm_fbdev_fini(drm_dev); > err_unbind_all: > component_unbind_all(dev, drm_dev); > -err_mode_config_cleanup: > - drm_mode_config_cleanup(drm_dev); > +err_iommu_cleanup: > rockchip_iommu_cleanup(drm_dev); > err_free: > - drm_dev->dev_private = NULL; > - dev_set_drvdata(dev, NULL); > drm_dev_put(drm_dev); > return ret; > } > @@ -194,11 +193,8 @@ static void rockchip_drm_unbind(struct device *dev) > > drm_atomic_helper_shutdown(drm_dev); > component_unbind_all(dev, drm_dev); > - drm_mode_config_cleanup(drm_dev); > rockchip_iommu_cleanup(drm_dev); > > - drm_dev->dev_private = NULL; > - dev_set_drvdata(dev, NULL); > drm_dev_put(drm_dev); > } > > -- > 2.24.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 35/51] drm/pl111: Drop explicit drm_mode_config_cleanup call
On Mon, Mar 02, 2020 at 11:26:15PM +0100, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> Aside: This driver gets its devm_ stuff all wrong wrt drm_device and
> anything hanging off that. Not the only one unfortunately.
>
> v2: Explain why this cleanup is possible (Laurent).
>
> v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
>
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Eric Anholt
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/pl111/pl111_drv.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index aa8aa8d9e405..f9ca0f3edbbb 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -90,10 +90,13 @@ static int pl111_modeset_init(struct drm_device *dev)
> struct drm_panel *panel = NULL;
> struct drm_bridge *bridge = NULL;
> bool defer = false;
> - int ret = 0;
> + int ret;
> int i;
>
> - drm_mode_config_init(dev);
> + ret = drmm_mode_config_init(dev);
> + if (ret)
> + return ret;
> +
> mode_config = &dev->mode_config;
> mode_config->funcs = &mode_config_funcs;
> mode_config->min_width = 1;
> @@ -154,7 +157,7 @@ static int pl111_modeset_init(struct drm_device *dev)
> DRM_MODE_CONNECTOR_Unknown);
> if (IS_ERR(bridge)) {
> ret = PTR_ERR(bridge);
> - goto out_config;
> + goto finish;
> }
> } else if (bridge) {
> dev_info(dev->dev, "Using non-panel bridge\n");
> @@ -197,8 +200,6 @@ static int pl111_modeset_init(struct drm_device *dev)
> out_bridge:
> if (panel)
> drm_panel_bridge_remove(bridge);
> -out_config:
> - drm_mode_config_cleanup(dev);
> finish:
> return ret;
> }
> @@ -343,7 +344,6 @@ static int pl111_amba_remove(struct amba_device *amba_dev)
> drm_dev_unregister(drm);
> if (priv->panel)
> drm_panel_bridge_remove(priv->bridge);
> - drm_mode_config_cleanup(drm);
> drm_dev_put(drm);
> of_reserved_mem_device_release(dev);
>
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 25/51] drm: Garbage collect drm_dev_fini
On Mon, Mar 02, 2020 at 11:26:05PM +0100, Daniel Vetter wrote:
> It has become empty. Given the few users I figured not much point
> splitting this up.
>
> v2: Rebase over i915 changes.
>
> Signed-off-by: Daniel Vetter
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 1 -
> drivers/gpu/drm/drm_drv.c | 23 +--
> drivers/gpu/drm/drm_mipi_dbi.c| 1 -
> drivers/gpu/drm/i915/i915_drv.c | 9
> .../gpu/drm/i915/selftests/mock_gem_device.c | 2 --
> drivers/gpu/drm/ingenic/ingenic-drm.c | 1 -
> drivers/gpu/drm/mcde/mcde_drv.c | 1 -
> drivers/gpu/drm/tidss/tidss_drv.c | 2 --
> drivers/gpu/drm/tiny/gm12u320.c | 1 -
> drivers/gpu/drm/tiny/repaper.c| 1 -
> drivers/gpu/drm/udl/udl_drv.c | 1 -
> drivers/gpu/drm/vgem/vgem_drv.c | 1 -
> drivers/gpu/drm/vkms/vkms_drv.c | 1 -
> drivers/gpu/drm/xen/xen_drm_front.c | 2 --
> include/drm/drm_drv.h | 5 +---
> 15 files changed, 2 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index 2232556ce34c..a9d789a56536 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -529,7 +529,6 @@ static void cirrus_mode_config_init(struct cirrus_device
> *cirrus)
> static void cirrus_release(struct drm_device *dev)
> {
> drm_mode_config_cleanup(dev);
> - drm_dev_fini(dev);
> }
>
> DEFINE_DRM_GEM_FOPS(cirrus_fops);
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 90b6ae81d431..c709a0ce018c 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -283,7 +283,6 @@ void drm_minor_release(struct drm_minor *minor)
> * struct driver_device *priv = container_of(...);
> *
> * drm_mode_config_cleanup(drm);
> - * drm_dev_fini(drm);
> * }
> *
> * static struct drm_driver driver_drm_driver = {
> @@ -738,23 +737,6 @@ int devm_drm_dev_init(struct device *parent,
> }
> EXPORT_SYMBOL(devm_drm_dev_init);
>
> -/**
> - * drm_dev_fini - Finalize a dead DRM device
> - * @dev: DRM device
> - *
> - * Finalize a dead DRM device. This is the converse to drm_dev_init() and
> - * frees up all data allocated by it. All driver private data should be
> - * finalized first. Note that this function does not free the @dev, that is
> - * left to the caller.
> - *
> - * The ref-count of @dev must be zero, and drm_dev_fini() should only be
> called
> - * from a &drm_driver.release callback.
> - */
> -void drm_dev_fini(struct drm_device *dev)
> -{
> -}
> -EXPORT_SYMBOL(drm_dev_fini);
> -
> /**
> * drm_dev_alloc - Allocate new DRM device
> * @driver: DRM driver to allocate device for
> @@ -803,11 +785,8 @@ static void drm_dev_release(struct kref *ref)
> {
> struct drm_device *dev = container_of(ref, struct drm_device, ref);
>
> - if (dev->driver->release) {
> + if (dev->driver->release)
> dev->driver->release(dev);
> - } else {
> - drm_dev_fini(dev);
> - }
>
> drm_managed_release(dev);
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 069603dfcd10..a678e07508d4 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -591,7 +591,6 @@ void mipi_dbi_release(struct drm_device *drm)
> DRM_DEBUG_DRIVER("\n");
>
> drm_mode_config_cleanup(drm);
> - drm_dev_fini(drm);
> }
> EXPORT_SYMBOL(mipi_dbi_release);
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bb14209beeed..ff24ca5df7ed 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -911,13 +911,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return i915;
> }
>
> -static void i915_driver_destroy(struct drm_i915_private *i915)
> -{
> - struct pci_dev *pdev = i915->drm.pdev;
> -
> - drm_dev_fini(&i915->drm);
> -}
> -
> /**
> * i915_driver_probe - setup chip and create an initial config
> * @pdev: PCI device
> @@ -1020,7 +1013,6 @@ int i915_driver_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> pci_disable_device(pdev);
> out_fini:
> i915_probe_error(i915, "Device initialization failed (%d)\n", ret);
> - i915_driver_destroy(i915);
> drm_dev_put(&i915->drm);
> return ret;
> }
> @@ -1077,7 +1069,6 @@ static void i915_driver_release(struct drm_device *dev)
> intel_runtime_pm_driver_release(rpm);
>
> i915_driver_late_release(dev_priv);
> - i915_driver_destroy(dev_priv);
> }
>
> static int i915_driver_open(struct drm_device *dev, struct drm_file *file)
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> b/drivers/gpu/drm/i915/sel
Re: [PATCH 24/51] drm: Manage drm_vblank_cleanup with drmm_
On Mon, Mar 02, 2020 at 11:26:04PM +0100, Daniel Vetter wrote:
> Nothing special here, except that this is the first time that we
> automatically clean up something that's initialized with an explicit
> driver call. But the cleanup was done at the very of the release
the very what?
> sequence for all drivers, and that's still the case. At least without
> more uses of drmm_ through explicit driver calls.
This patch does not simplify things in itself.
The motivation here is to remove the drm_dev_fini()
dependencies from the drivers.
So drm_dev_fini() can be dropped in a follow-up patch.
Maybe extend the changelog a little?
> Also for this one we need drmm_kcalloc, so lets add those
>
> v2: Sort includes (Laurent)
>
> Signed-off-by: Daniel Vetter
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_drv.c | 1 -
> drivers/gpu/drm/drm_internal.h | 1 -
> drivers/gpu/drm/drm_vblank.c | 31 ---
> include/drm/drm_managed.h | 16
> 4 files changed, 28 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 9a646155dfc6..90b6ae81d431 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -752,7 +752,6 @@ EXPORT_SYMBOL(devm_drm_dev_init);
> */
> void drm_dev_fini(struct drm_device *dev)
> {
> - drm_vblank_cleanup(dev);
> }
> EXPORT_SYMBOL(drm_dev_fini);
>
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index cb09e95a795e..e67015d07c4c 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -94,7 +94,6 @@ void drm_managed_release(struct drm_device *dev);
>
> /* drm_vblank.c */
> void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe);
> -void drm_vblank_cleanup(struct drm_device *dev);
>
> /* IOCTLS */
> int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 47fc4339ec7f..5a6ec8aa0873 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -425,14 +426,10 @@ static void vblank_disable_fn(struct timer_list *t)
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> }
>
> -void drm_vblank_cleanup(struct drm_device *dev)
> +static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
> {
> unsigned int pipe;
>
> - /* Bail if the driver didn't call drm_vblank_init() */
> - if (dev->num_crtcs == 0)
> - return;
> -
> for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>
> @@ -441,10 +438,6 @@ void drm_vblank_cleanup(struct drm_device *dev)
>
> del_timer_sync(&vblank->disable_timer);
> }
> -
> - kfree(dev->vblank);
> -
> - dev->num_crtcs = 0;
> }
>
> /**
> @@ -453,25 +446,29 @@ void drm_vblank_cleanup(struct drm_device *dev)
> * @num_crtcs: number of CRTCs supported by @dev
> *
> * This function initializes vblank support for @num_crtcs display pipelines.
> - * Cleanup is handled by the DRM core, or through calling drm_dev_fini() for
> - * drivers with a &drm_driver.release callback.
> + * Cleanup is handled automatically through a cleanup function added with
> + * drmm_add_action().
> *
> * Returns:
> * Zero on success or a negative error code on failure.
> */
> int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs)
> {
> - int ret = -ENOMEM;
> + int ret;
> unsigned int i;
>
> spin_lock_init(&dev->vbl_lock);
> spin_lock_init(&dev->vblank_time_lock);
>
> + dev->vblank = drmm_kcalloc(dev, num_crtcs, sizeof(*dev->vblank),
> GFP_KERNEL);
> + if (!dev->vblank)
> + return -ENOMEM;
> +
> dev->num_crtcs = num_crtcs;
>
> - dev->vblank = kcalloc(num_crtcs, sizeof(*dev->vblank), GFP_KERNEL);
> - if (!dev->vblank)
> - goto err;
> + ret = drmm_add_action(dev, drm_vblank_init_release, NULL);
> + if (ret)
> + return ret;
>
> for (i = 0; i < num_crtcs; i++) {
> struct drm_vblank_crtc *vblank = &dev->vblank[i];
> @@ -486,10 +483,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
> num_crtcs)
> DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
>
> return 0;
> -
> -err:
> - dev->num_crtcs = 0;
> - return ret;
> }
> EXPORT_SYMBOL(drm_vblank_init);
>
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index 5280209dff92..2b1ba2ad5582 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -4,6 +4,7 @@
> #define _DRM_MANAGED_H_
>
> #include
> +#include
> #include
>
> struct drm_device;
> @@ -28,6 +29,21 @@ static inline void *drmm_kzalloc(struct drm_device *dev,
Re: [PATCH 23/51] drm: Manage drm_gem_init with drmm_
Hi Daniel.
On Mon, Mar 02, 2020 at 11:26:03PM +0100, Daniel Vetter wrote:
> We might want to look into pushing this down into drm_mm_init, but
> that would mean rolling out return codes to a pile of functions
> unfortunately. So let's leave that for now.
>
> Signed-off-by: Daniel Vetter
We are loosing this part of the destroy function:
dev->vma_offset_manager = NULL;
But there was no code that I could find that relied on this, so this
should be OK.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_drv.c | 8 +---
> drivers/gpu/drm/drm_gem.c | 21 ++---
> drivers/gpu/drm/drm_internal.h | 1 -
> 3 files changed, 11 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 29d106195ab3..9a646155dfc6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -688,13 +688,10 @@ int drm_dev_init(struct drm_device *dev,
>
> ret = drm_dev_set_unique(dev, dev_name(parent));
> if (ret)
> - goto err_setunique;
> + goto err;
>
> return 0;
>
> -err_setunique:
> - if (drm_core_check_feature(dev, DRIVER_GEM))
> - drm_gem_destroy(dev);
> err:
> drm_managed_release(dev);
>
> @@ -756,9 +753,6 @@ EXPORT_SYMBOL(devm_drm_dev_init);
> void drm_dev_fini(struct drm_device *dev)
> {
> drm_vblank_cleanup(dev);
> -
> - if (drm_core_check_feature(dev, DRIVER_GEM))
> - drm_gem_destroy(dev);
> }
> EXPORT_SYMBOL(drm_dev_fini);
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 0b6e6623735e..31095e0f6b9f 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -77,6 +78,12 @@
> * up at a later date, and as our interface with shmfs for memory allocation.
> */
>
> +static void
> +drm_gem_init_release(struct drm_device *dev, void *ptr)
> +{
> + drm_vma_offset_manager_destroy(dev->vma_offset_manager);
> +}
> +
> /**
> * drm_gem_init - Initialize the GEM device fields
> * @dev: drm_devic structure to initialize
> @@ -89,7 +96,8 @@ drm_gem_init(struct drm_device *dev)
> mutex_init(&dev->object_name_lock);
> idr_init_base(&dev->object_name_idr, 1);
>
> - vma_offset_manager = kzalloc(sizeof(*vma_offset_manager), GFP_KERNEL);
> + vma_offset_manager = drmm_kzalloc(dev, sizeof(*vma_offset_manager),
> + GFP_KERNEL);
> if (!vma_offset_manager) {
> DRM_ERROR("out of memory\n");
> return -ENOMEM;
> @@ -100,16 +108,7 @@ drm_gem_init(struct drm_device *dev)
> DRM_FILE_PAGE_OFFSET_START,
> DRM_FILE_PAGE_OFFSET_SIZE);
>
> - return 0;
> -}
> -
> -void
> -drm_gem_destroy(struct drm_device *dev)
> -{
> -
> - drm_vma_offset_manager_destroy(dev->vma_offset_manager);
> - kfree(dev->vma_offset_manager);
> - dev->vma_offset_manager = NULL;
> + return drmm_add_action(dev, drm_gem_init_release, NULL);
> }
>
> /**
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 8c2628dfc6c7..cb09e95a795e 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -144,7 +144,6 @@ void drm_sysfs_lease_event(struct drm_device *dev);
> /* drm_gem.c */
> struct drm_gem_object;
> int drm_gem_init(struct drm_device *dev);
> -void drm_gem_destroy(struct drm_device *dev);
> int drm_gem_handle_create_tail(struct drm_file *file_priv,
> struct drm_gem_object *obj,
> u32 *handlep);
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/51] drm: Set final_kfree in drm_dev_alloc
On Mon, Mar 02, 2020 at 11:25:44PM +0100, Daniel Vetter wrote: > I also did a full review of all callers, and only the xen driver > forgot to call drm_dev_put in the failure path. Fix that up too. So ~40 callers - phew.. > > v2: I noticed that xen has a drm_driver.release hook, and uses > drm_dev_alloc(). We need to remove the kfree from > xen_drm_drv_release(). > > bochs also has a release hook, but leaked the drm_device ever since > > commit 0a6659bdc5e8221da99eebb176fd9591435e38de > Author: Gerd Hoffmann > Date: Tue Dec 17 18:04:46 2013 +0100 > > drm/bochs: new driver > > This patch here fixes that leak. > > Same for virtio, started leaking with > > commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a > Author: Gerd Hoffmann > Date: Tue Feb 11 14:58:04 2020 +0100 > > drm/virtio: add drm_driver.release callback. > > Cc: Gerd Hoffmann > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org The above will be picked up by tools as regular Cc: lines. But I guess it is fine. > > Reviewed-by: Oleksandr Andrushchenko > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org For the drivers I looked at everything looked fine. Acked-by: Sam Ravnborg > --- > drivers/gpu/drm/drm_drv.c | 3 +++ > drivers/gpu/drm/xen/xen_drm_front.c | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index 153050fc926c..7b84ee8a5eb5 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -819,6 +820,8 @@ struct drm_device *drm_dev_alloc(struct drm_driver > *driver, > return ERR_PTR(ret); > } > > + drmm_add_final_kfree(dev, dev); > + > return dev; > } > EXPORT_SYMBOL(drm_dev_alloc); > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 4be49c1aef51..d22b5da38935 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -461,7 +461,6 @@ static void xen_drm_drv_release(struct drm_device *dev) > drm_mode_config_cleanup(dev); > > drm_dev_fini(dev); > - kfree(dev); > > if (front_info->cfg.be_alloc) > xenbus_switch_state(front_info->xb_dev, > @@ -561,6 +560,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info > *front_info) > fail_modeset: > drm_kms_helper_poll_fini(drm_dev); > drm_mode_config_cleanup(drm_dev); > + drm_dev_put(drm_dev); > fail: > kfree(drm_info); > return ret; > -- > 2.24.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
