Re: [RESEND PATCH v6 00/27] DRM Rockchip rk3399 (Kevin)
On 23.04.2018 12:49, Enric Balletbo i Serra wrote: > Hi Andrzej, > > This is the rebased version of v6 series. This patchset includes cleanups, > improvements, and bug fixes for Rockchip DRM driver and PSR support. > > This version is a RESEND of v6 with few changes. The following two > patches are not included and will be send in a separate patchset for > further discussion. > > - [PATCH v6 24/30] drm/rockchip: Disable PSR on input events > - [PATCH v6 25/30] drm/rockchip: Cancel PSR enable work before changing >the state > > The following patch was remove as is not needed. > > - [PATCH v6 28/30] drm/rockchip: Disable PSR from reboot notifier > > I think that the other patches have the required tags and are ready to > be merged. Queued to drm-misc-next. Regards Andrzej > > Regards, > Enric > > Changes in v6: > - Removed the following patches as are already applied. > [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after > configuring the PSR > [PATCH v5 02/36] drm/rockchip: Remove analogix psr worker > [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while > bridge is disabled > - Explain in the commit message why we need to increase > the delay in the timeout loop in > [PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into > config_video() > - Add Reviewed-by: Archit Taneja for the > drm/bridge parts > - Add Reviewed-by: Heiko Stuebner for > [PATCH v5 19/36] drm/rockchip: Restore psr->state when enable/disable > psr failed > > Changes in v5: > - Removed the following patches as are already applied. > [PATCH v4 01/38] drm/bridge: analogix_dp: set psr activate/deactivate > when enable/disable bridge > [PATCH v4 02/38] drm/rockchip: Don't use atomic constructs for psr > - Add Mareks tested-tag and including the missing people. > - [PATCH v4 15/38] move analogix_dp_set_analog_power_down() before > phy_power_off() to fix Exynos issue. > > Changes in v4: > - Rebased all on top of drm-misc-next > - Removed the following patches as are already applied. > [PATCH v3 01/43] drm/rockchip: Get rid of unnecessary struct fields > [PATCH v3 02/43] drm/rockchip: support prime import sg table > [PATCH v3 03/43] drm/rockchip: Respect page offset for PRIME mmap > calls > - Removed the following patches as now are part of another patchset > [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in > analogix_dp_bind > [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31 > > Changes in v3: > - Addressed some of the comments from Sean on the v2 > > Changes in v2: > - A few patches have been replaced by newer and cleaner versions from > the ChromeOS kernel gerrit, especially about disallowing PSR for the > whole atomic commit. > > > Douglas Anderson (4): > drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner > drm/bridge: analogix_dp: Properly log AUX CH errors > drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip > drm/bridge: analogix_dp: Split the platform-specific poweron in two > parts > > Lin Huang (6): > drm/bridge: analogix_dp: Move enable video into config_video() > drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer > drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the > panel > drm/bridge: analogix_dp: Extend hpd check time to 100ms > drm/bridge: analogix_dp: Check dpcd write/read status > drm/bridge: analogix_dp: Reset aux channel if an error occurred > > Mark Yao (1): > drm/rockchip: pre dither down when output bpc is 8bit > > Tomasz Figa (5): > drm/rockchip: analogix_dp: Do not call Analogix code before bind > drm/rockchip: psr: Avoid redundant calls to .set() callback > drm/rockchip: psr: Sanitize semantics of allow/inhibit API > drm/rockchip: Disallow PSR for the whole atomic commit > drm/rockchip: psr: Remove flush by CRTC > > zain wang (11): > drm/bridge: analogix_dp: Don't use fast link training when panel just > powered up > drm/bridge: analogix_dp: Retry bridge enable when it failed > drm/bridge: analogix_dp: Wait for HPD signal before configuring link > drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy > drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode > drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip > drm/rockchip: Restore psr->state when enable/disable psr failed > drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll > drm/bridge: analogix_dp: Fix timeout of video streamclk config > drm/bridge: analogix_dp: Fix incorrect operations with register > ANALOGIX_DP_FUNC_EN_1 > drm/bridge: analogix_dp: Move fast link training detect to set_bridge > > .../drm/bridge/analogix/analogix_dp_core.c| 331 +- > .../drm/bridge/analogix/analogix_dp_core.h| 5 +- > .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 236 +++-- > .../gpu/drm/bridge/analogix/analogi
[Bug 91808] trine1 misrender r600g
https://bugs.freedesktop.org/show_bug.cgi?id=91808 --- Comment #12 from Hamish Wilson --- (In reply to Dave Airlie from comment #11) > Created attachment 139029 [details] [review] > attempted fix I have tried applying the patch to my Mesa package using the Arch Build System, but unfortunately it does not appear to have corrected the artifacts. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2 00/10] arm/arm64: mediatek: Fix mmsys device probing
On Mon, 23 Apr 2018, matthias@kernel.org wrote: > From: Matthias Brugger > > Changes since v1: > - add binding documentation > - ddp: use regmap_update_bits > - ddp: ignore EPROBE_DEFER on clock probing > - mfd: delete mmsys_private > - add Reviewed-by and Acked-by tags I'm confused by the double submission. Please can you send it again completely detached from the first and the second submissions please? > --- > > MMSYS in Mediatek SoCs has some registers to control clock gates (which is > used in the clk driver) and some registers to set the routing and enable > the differnet blocks of the display subsystem. > > Up to now both drivers, clock and drm are probed with the same device tree > compatible. But only the first driver get probed, which in effect breaks > graphics on mt8173 and mt2701. > > This patch set introduces a new mfd device, which binds against the mmsys > compatible and takes care of probing the needed devices. It was tested on the > bananapi-r2 and the Acer R13 Chromebook. > > > Matthias Brugger (10): > dt-bindings: mediatek: mmsys: Add support for mfd > drm/mediatek: Use regmap for register access > mfd: mtk-mmsys: Add mmsys driver > drm/mediatek: mt2701: switch to mfd probing. > clk: mediatek: mt2701-mm: switch to mfd device > mfd: mtk-mmsys: Add mt8173 nodes > drm/mediatek: Add mfd support for mt8173 > clk: mediatek: mt8173-mm: switch to mfd device > drm: mediatek: Omit warning on probe defers > MAINTAINERS: update Mediatek Soc entry > > .../bindings/arm/mediatek/mediatek,mmsys.txt | 2 - > .../bindings/display/mediatek/mediatek,disp.txt| 2 +- > .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 +++ > MAINTAINERS| 2 + > drivers/clk/mediatek/clk-mt2701-mm.c | 10 +-- > drivers/clk/mediatek/clk-mt8173.c | 17 +++- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 4 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 -- > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 33 > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- > drivers/mfd/Kconfig| 9 +++ > drivers/mfd/Makefile | 2 + > drivers/mfd/mtk-mmsys.c| 93 > ++ > 14 files changed, 189 insertions(+), 59 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt > create mode 100644 drivers/mfd/mtk-mmsys.c > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/24/2018 01:41 AM, Boris Ostrovsky wrote: On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote: On 04/23/2018 02:52 PM, Wei Liu wrote: On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: the gntdev. I think this is generic enough that it could be implemented by a device not tied to Xen. AFAICT the hyper_dma guys also wanted something similar to this. You can't just wrap random userspace memory into a dma-buf. We've just had this discussion with kvm/qemu folks, who proposed just that, and after a bit of discussion they'll now try to have a driver which just wraps a memfd into a dma-buf. So, we have to decide either we introduce a new driver (say, under drivers/xen/xen-dma-buf) or extend the existing gntdev/balloon to support dma-buf use-cases. Can anybody from Xen community express their preference here? Oleksandr talked to me on IRC about this, he said a few IOCTLs need to be added to either existing drivers or a new driver. I went through this thread twice and skimmed through the relevant documents, but I couldn't see any obvious pros and cons for either approach. So I don't really have an opinion on this. But, assuming if implemented in existing drivers, those IOCTLs need to be added to different drivers, which means userspace program needs to write more code and get more handles, it would be slightly better to implement a new driver from that perspective. If gntdev/balloon extension is still considered: All the IOCTLs will be in gntdev driver (in current xen-zcopy terminology): - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE Balloon driver extension, which is needed for contiguous/DMA buffers, will be to provide new *kernel API*, no UAPI is needed. So I am obviously a bit late to this thread, but why do you need to add new ioctls to gntdev and balloon? Doesn't this driver manage to do what you want without any extensions? 1. I only (may) need to add IOCTLs to gntdev 2. balloon driver needs to be extended, so it can allocate contiguous (DMA) memory, not IOCTLs/UAPI here, all lives in the kernel. 3. The reason I need to extend gnttab with new IOCTLs is to provide new functionality to create a dma-buf from grant references and to produce grant references for a dma-buf. This is what I have as UAPI description for xen-zcopy driver: 1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS This will create a DRM dumb buffer from grant references provided by the frontend. The intended usage is: - Frontend - creates a dumb/display buffer and allocates memory - grants foreign access to the buffer pages - passes granted references to the backend - Backend - issues DRM_XEN_ZCOPY_DUMB_FROM_REFS ioctl to map granted references and create a dumb buffer - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD - requests real HW driver/consumer to import the PRIME buffer with DRM_IOCTL_PRIME_FD_TO_HANDLE - uses handle returned by the real HW driver - at the end: o closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE o closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE o closes file descriptor of the exported buffer 2. DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS This will grant references to a dumb/display buffer's memory provided by the backend. The intended usage is: - Frontend - requests backend to allocate dumb/display buffer and grant references to its pages - Backend - requests real HW driver to create a dumb with DRM_IOCTL_MODE_CREATE_DUMB - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD - requests zero-copy driver to import the PRIME buffer with DRM_IOCTL_PRIME_FD_TO_HANDLE - issues DRM_XEN_ZCOPY_DUMB_TO_REFS ioctl to grant references to the buffer's memory. - passes grant references to the frontend - at the end: - closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE - closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE - closes file descriptor of the imported buffer 3. DRM_XEN_ZCOPY_DUMB_WAIT_FREE This will block until the dumb buffer with the wait handle provided be freed: this is needed for synchronization between frontend and backend in case frontend provides grant references of the buffer via DRM_XEN_ZCOPY_DUMB_FROM_REFS IOCTL and which must be released before backend replies with XENDISPL_OP_DBUF_DESTROY response. wait_handle must be the same value returned while calling DRM_XEN_ZCOPY_DUMB_FROM_REFS IOCTL. So, as you can see the above functionality is not covered by the existing UAPI of the gntdev driver. Now, if we change dumb -> dma-buf and remove DRM code (which is only a wrapper here on top of dma-buf) we get new driver for dma-buf for Xen. This is why I have 2 options here: either create a dedicated driver for this (e.g. re-work xen-zcopy to be DRM independent and put it under drivers/xen/xen-dma-buf, for example) or extend the existing g
Re: [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits
On 4/23/2018 3:43 PM, Ville Syrjälä wrote: On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote: On 4/20/2018 7:42 PM, Ville Syrjälä wrote: On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote: From: Ankit Nautiyal This patch adds helper functions for determining if aspect-ratio is expected in user-mode and for allowing/disallowing the aspect-ratio, if its not expected. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/drm_modes.c | 47 + include/drm/drm_modes.h | 4 2 files changed, 51 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index c395a24..d6133e8 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1759,3 +1759,50 @@ bool drm_mode_is_420(const struct drm_display_info *display, drm_mode_is_420_also(display, mode); } EXPORT_SYMBOL(drm_mode_is_420); + +/** + * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information + * is expected from the user-mode. + * + * If the user has set aspect-ratio cap, then the flag of the user-mode is + * allowed to contain aspect-ratio value. + * If the user does not set aspect-ratio cap, then the only value allowed in the + * flags bits is aspect-ratio NONE. + * + * @file_priv: file private structure to get the user capabilities + * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio + * information. + * + * Returns: + * true if the aspect-ratio info is allowed in the user-mode flags. + * false, otherwise. + */ +bool +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, +struct drm_mode_modeinfo *umode) +{ + return file_priv->aspect_ratio_allowed || (umode->flags & + DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE; Odd line split here. Makes this a bit hard to read. I would split after the || Agreed. I wasn't sure how to let it have better readability and less than 80 char length at the same time. Will fix this. +} +EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed); Do we actually need to export these? I don't think so. But I might be wrong. It's a bit hard to see with the way you split this patch with the actual users in a different patch. These helper functions are used in drm_mode_atomic.c, drm_mode_crtc.c, and drm_mode_get_connector.c The patches are split as to have modes-set handling separate and the exposing of connector separate. Do you suggest this patch to be merged with the patch for handling aspect-ratio in modeset? Usually if you add a function you should do it in the same patch where you add the user(s) for said function. Otherwise it's impossibly to judge whether the new function is any good. That makes sense. I will merge this patch with the patch for handling aspect ratio in modeset path, where its actually used. + +/** + * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the + * user-mode flags. + * + * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio + * bits in the user-mode flags, if aspect-ratio info is not allowed. + * + * @file_priv: file private structure to get the user capabilities. + * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to + * be filtered. + * + */ +void +drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode) +{ + if (!drm_mode_aspect_ratio_allowed(file_priv, umode)) + umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK; +} +EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags); diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h index 2f78b7e..e0b060d 100644 --- a/include/drm/drm_modes.h +++ b/include/drm/drm_modes.h @@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info *display, const struct drm_display_mode *mode); bool drm_mode_is_420(const struct drm_display_info *display, const struct drm_display_mode *mode); +bool drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode); +void drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode); struct drm_display_mode *drm_cvt_mode(struct drm_device *dev, int hdisplay, int vdisplay, int vrefresh, -- 2.7.4 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits
On 4/23/2018 3:52 PM, Jani Nikula wrote: On Mon, 23 Apr 2018, "Nautiyal, Ankit K" wrote: On 4/20/2018 7:42 PM, Ville Syrjälä wrote: On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote: From: Ankit Nautiyal +bool +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode) +{ + return file_priv->aspect_ratio_allowed || (umode->flags & + DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE; Odd line split here. Makes this a bit hard to read. I would split after the || Agreed. I wasn't sure how to let it have better readability and less than 80 char length at the same time. Will fix this. 80 chars is not a strict requirement. Readability is. ;) BR, Jani. Roger that! :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/2] drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag
Please use "PATCH hwc" for drm_hwcomposer patches. On Mon, Apr 23, 2018 at 7:06 PM, John Stultz wrote: > The drm_hwcomposer has its own GL pre-compositor which is used > to squish layers when there are more layers then planes on the > display hardware. In many ways this duplicates the client-side > GL compositing that is done in SurfaceFlinger, but in theory can > be more highly optimized for the hardware. > > Unfortunately, due to these optimizations, the drm_hwcomposer's > pre-compositor becomes somewhat hardware specific (originally > targeting nvidia hardware, I believe). > > So on some hardware, the gl precompositor may not actually > initialize due to hardware missing features, or the hardware > supporting different shader APIs. > > Rather then try to rework the drm_hwcomposers precompositor > to be more generic, I instead suggest that when the > precompositor fails to initialize, we simply fall back to the > already more widely compatible client compositor in > SurfaceFlinger. > > Thus, this patch cleans up some of the precompositor > initialization, which didn't handle failures well. > > Feedback or alternative ideas would be greatly appreciated! > > Cc: Marissa Wall > Cc: Sean Paul > Cc: Dmitry Shmidt > Cc: Robert Foss > Cc: Matt Szczesiak > Cc: Liviu Dudau > Cc: David Hanna > Cc: Rob Herring > Cc: Alexandru-Cosmin Gheorghe > Cc: Alistair Strachan > Signed-off-by: John Stultz > --- > drmdisplaycompositor.cpp | 40 +--- > drmdisplaycompositor.h | 3 +++ > 2 files changed, 24 insertions(+), 19 deletions(-) Both patches look good to me. Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v6 16/27] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote: > > From: zain wang > > Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to > Exynos: > > on Exynos edp phy, > BIT 7 MASTER_VID_FUNC_EN_N > BIT 6 reserved > BIT 5 SLAVE_VID_FUNC_EN_N > > on Rockchip edp phy, > BIT 7 reserved > BIT 6 RK_VID_CAP_FUNC_EN_N > BIT 5 RK_VID_FIFO_FUNC_EN_N > > So, we should do some private operations to Rockchip. > > Cc: Tomasz Figa > Signed-off-by: zain wang > Signed-off-by: Sean Paul > Signed-off-by: Thierry Escande > Reviewed-by: Andrzej Hajda > Signed-off-by: Enric Balletbo i Serra > Tested-by: Marek Szyprowski > Reviewed-by: Archit Taneja Acked-by: Jingoo Han Best regards, Jingoo Han > --- > > .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++- > .../gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 ++ > 2 files changed, 16 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > index 02ab1aaa9993..4eae206ec31b 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > @@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp) > analogix_dp_stop_video(dp); > analogix_dp_enable_video_mute(dp, 0); > > - reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N | > - AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N | > - HDCP_FUNC_EN_N | SW_FUNC_EN_N; > + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) > + reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N | > + SW_FUNC_EN_N; > + else > + reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N | > + AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N | > + HDCP_FUNC_EN_N | SW_FUNC_EN_N; > + > writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1); > > reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N | > @@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct > analogix_dp_device *dp) > u32 reg; > > reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1); > - reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N); > - reg |= MASTER_VID_FUNC_EN_N; > + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) { > + reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N); > + } else { > + reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N); > + reg |= MASTER_VID_FUNC_EN_N; > + } > writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1); > > reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10); > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h > b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h > index b633a4a5082a..0cf27c731727 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h > @@ -127,7 +127,9 @@ > > /* ANALOGIX_DP_FUNC_EN_1 */ > #define MASTER_VID_FUNC_EN_N (0x1 << 7) > +#define RK_VID_CAP_FUNC_EN_N (0x1 << 6) > #define SLAVE_VID_FUNC_EN_N (0x1 << 5) > +#define RK_VID_FIFO_FUNC_EN_N(0x1 << 5) > #define AUD_FIFO_FUNC_EN_N (0x1 << 4) > #define AUD_FUNC_EN_N(0x1 << 3) > #define HDCP_FUNC_EN_N (0x1 << 2) > -- > 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v6 14/27] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote: > > From: zain wang > > There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg > list. We should use BIT_4 in ANALOGIX_DP_PD to control the pll power > instead of ANALOGIX_DP_PLL_CTL. > > Cc: Douglas Anderson > Signed-off-by: zain wang > Signed-off-by: Sean Paul > Signed-off-by: Thierry Escande > Reviewed-by: Andrzej Hajda > Signed-off-by: Enric Balletbo i Serra > Tested-by: Marek Szyprowski > Reviewed-by: Archit Taneja Acked-by: Jingoo Han Best regards, Jingoo Han > --- > > .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 +++ > 1 file changed, 12 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > index 7b7fd227e1f9..02ab1aaa9993 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > @@ -230,16 +230,20 @@ enum pll_status > analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp) > void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool > enable) > { > u32 reg; > + u32 mask = DP_PLL_PD; > + u32 pd_addr = ANALOGIX_DP_PLL_CTL; > > - if (enable) { > - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL); > - reg |= DP_PLL_PD; > - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL); > - } else { > - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL); > - reg &= ~DP_PLL_PD; > - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL); > + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) { > + pd_addr = ANALOGIX_DP_PD; > + mask = RK_PLL_PD; > } > + > + reg = readl(dp->reg_base + pd_addr); > + if (enable) > + reg |= mask; > + else > + reg &= ~mask; > + writel(reg, dp->reg_base + pd_addr); > } > > void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp, > -- > 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106199] Cannot get back into DM after logoff (Linux 4.16.2+)
https://bugs.freedesktop.org/show_bug.cgi?id=106199 Bug ID: 106199 Summary: Cannot get back into DM after logoff (Linux 4.16.2+) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: m...@elbmurf.de Created attachment 139031 --> https://bugs.freedesktop.org/attachment.cgi?id=139031&action=edit LightDM ant soccer Starting with Linux 4.16.2, when I logoff from KDE Plasma, I don’t get back into SDDM (just a black screen) or back into LightDM (wild random blocky screen, see attachment). I have a RX 580, DC is on. Same result on Linux 4.17rc2. Distro is Antergos/Arch. Monitor is connected via DP. Using SDDM, I can press ctrl + alt + F1 etc. to theoretically get to a tty prompt but the screen does stay black. But then, after pressing ctrl + alt + del numerous times, at least my system does a proper reboot. In LightDM, this does not work and I have to use the reset button. Worked with Linux 4.16.1 before. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+
This driver will be used to support Mesa on the Broadcom 7268 and 7278 platforms. V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's complicated CL/shader validation scheme. This massively changes the GEM behavior, so I've forked off to a new driver. v2: Mark SUBMIT_CL as needing DRM_AUTH. coccinelle fixes from kbuild test robot. Drop personal git link from MAINTAINERS. Don't double-map dma-buf imported BOs. Add kerneldoc about needing MMU eviction. Drop prime vmap/unmap stubs. Delay mmap offset setup to mmap time. Use drm_dev_init instead of _alloc. Use ktime_get() for wait_bo timeouts. Drop drm_can_sleep() usage, since we don't modeset. Switch page tables back to WC (debug change to coherent had slipped in). Switch drm_gem_object_unreference_unlocked() to drm_gem_object_put_unlocked(). Simplify overflow mem handling by not sharing overflow mem between jobs. Signed-off-by: Eric Anholt Acked-by: Daniel Vetter --- Documentation/gpu/drivers.rst | 1 + MAINTAINERS| 8 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/v3d/Kconfig| 9 + drivers/gpu/drm/v3d/Makefile | 18 + drivers/gpu/drm/v3d/v3d_bo.c | 379 ++ drivers/gpu/drm/v3d/v3d_debugfs.c | 191 +++ drivers/gpu/drm/v3d/v3d_drv.c | 371 ++ drivers/gpu/drm/v3d/v3d_drv.h | 294 +++ drivers/gpu/drm/v3d/v3d_fence.c| 58 +++ drivers/gpu/drm/v3d/v3d_gem.c | 663 + drivers/gpu/drm/v3d/v3d_irq.c | 206 drivers/gpu/drm/v3d/v3d_mmu.c | 122 + drivers/gpu/drm/v3d/v3d_regs.h | 295 +++ drivers/gpu/drm/v3d/v3d_sched.c| 228 + drivers/gpu/drm/v3d/v3d_trace.h| 82 +++ drivers/gpu/drm/v3d/v3d_trace_points.c | 9 + include/uapi/drm/v3d_drm.h | 191 +++ 19 files changed, 3128 insertions(+) create mode 100644 drivers/gpu/drm/v3d/Kconfig create mode 100644 drivers/gpu/drm/v3d/Makefile create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c create mode 100644 include/uapi/drm/v3d_drm.h diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index d3ab6abae838..f982558fc25d 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -10,6 +10,7 @@ GPU Driver Documentation tegra tinydrm tve200 + v3d vc4 bridge/dw-hdmi xen-front diff --git a/MAINTAINERS b/MAINTAINERS index bca3c32fb141..46c49c02d87b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4795,6 +4795,14 @@ S: Maintained F: drivers/gpu/drm/omapdrm/ F: Documentation/devicetree/bindings/display/ti/ +DRM DRIVERS FOR V3D +M: Eric Anholt +S: Supported +F: drivers/gpu/drm/v3d/ +F: include/uapi/drm/v3d_drm.h +F: Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt +T: git git://anongit.freedesktop.org/drm/drm-misc + DRM DRIVERS FOR VC4 M: Eric Anholt T: git git://github.com/anholt/linux diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 757825ac60df..1c73a455fdb1 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -267,6 +267,8 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig" source "drivers/gpu/drm/imx/Kconfig" +source "drivers/gpu/drm/v3d/Kconfig" + source "drivers/gpu/drm/vc4/Kconfig" source "drivers/gpu/drm/etnaviv/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 9d66657ea117..7a401edd8761 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ +obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ obj-$(CONFIG_DRM_SIS) += sis/ diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig new file mode 100644 index ..a0c0259355bd --- /dev/null +++ b/drivers/gpu/drm/v3d/Kconfig @@ -0,0 +1,9 @@ +config DRM_V3D + tristate "Broadcom V3D 3.x and newer" + depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST + depends on DRM + depends on COMMON_CLK + select DRM_SCHED + help + Choose this option if you
[PATCH v2 2/3] dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.
These OpenGL ES GPUs are present in the 7268 and 7278 set top box chips. Signed-off-by: Eric Anholt --- .../bindings/display/brcm,bcm-v3d.txt | 28 +++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt b/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt new file mode 100644 index ..1c814714de0e --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt @@ -0,0 +1,28 @@ +Broadcom V3D GPU + +Only the Broadcom V3D 3.x and newer GPUs are covered by this binding. +For V3D 2.x, see brcm,bcm-vc4.txt. + +Required properties: +- compatible: Should be "brcm,7268-v3d" or "brcm,7278-v3d" +- reg: Physical base addresses and lengths of the register areas +- reg-names: Names for the register areas. The "hub", "bridge", and "core0" + register areas are always required. The "gca" register area + is required if the GCA cache controller is present. +- interrupts: The interrupt numbers. The first interrupt is for the hub, + while the following inerrupts are for the cores. + See bindings/interrupt-controller/interrupts.txt + +Optional properties: +- clocks: The core clock the unit runs on + +v3d { + compatible = "brcm,7268-v3d"; + reg = <0xf1204000 0x100>, + <0xf120 0x4000>, + <0xf1208000 0x4000>, + <0xf1204100 0x100>; + reg-names = "bridge", "hub", "core0", "gca"; + interrupts = <0 78 4>, +<0 77 4>; +}; -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] V3D DRM driver
Here's v2 of the driver. This is mostly handling danvet's feedback, but there are a couple of other changes: - new core patch for prime vmap/vunmap - kbuild test robot fixes - overflow mem simplification (figured it out over breakfast with keithp) - drm_gem_object_unreference_unlocked() to _put_unlocked(). Eric Anholt (3): drm: Make the prime vmap/vunmap hooks optional. dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs. drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+ .../bindings/display/brcm,bcm-v3d.txt | 28 + Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_prime.c | 8 +- drivers/gpu/drm/v3d/Kconfig | 9 + drivers/gpu/drm/v3d/Makefile | 18 + drivers/gpu/drm/v3d/v3d_bo.c | 379 ++ drivers/gpu/drm/v3d/v3d_debugfs.c | 191 + drivers/gpu/drm/v3d/v3d_drv.c | 371 ++ drivers/gpu/drm/v3d/v3d_drv.h | 294 drivers/gpu/drm/v3d/v3d_fence.c | 58 ++ drivers/gpu/drm/v3d/v3d_gem.c | 663 ++ drivers/gpu/drm/v3d/v3d_irq.c | 206 ++ drivers/gpu/drm/v3d/v3d_mmu.c | 122 drivers/gpu/drm/v3d/v3d_regs.h| 295 drivers/gpu/drm/v3d/v3d_sched.c | 228 ++ drivers/gpu/drm/v3d/v3d_trace.h | 82 +++ drivers/gpu/drm/v3d/v3d_trace_points.c| 9 + include/uapi/drm/v3d_drm.h| 191 + 21 files changed, 3162 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt create mode 100644 drivers/gpu/drm/v3d/Kconfig create mode 100644 drivers/gpu/drm/v3d/Makefile create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c create mode 100644 include/uapi/drm/v3d_drm.h -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm: Make the prime vmap/vunmap hooks optional.
Some drivers leave these unimplemented, so don't make them have unimplemented stubs. Signed-off-by: Eric Anholt --- drivers/gpu/drm/drm_prime.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index caf675e3e692..397b46b33739 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -409,7 +409,10 @@ void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf) struct drm_gem_object *obj = dma_buf->priv; struct drm_device *dev = obj->dev; - return dev->driver->gem_prime_vmap(obj); + if (dev->driver->gem_prime_vmap) + return dev->driver->gem_prime_vmap(obj); + else + return NULL; } EXPORT_SYMBOL(drm_gem_dmabuf_vmap); @@ -426,7 +429,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr) struct drm_gem_object *obj = dma_buf->priv; struct drm_device *dev = obj->dev; - dev->driver->gem_prime_vunmap(obj, vaddr); + if (dev->driver->gem_prime_vunmap) + dev->driver->gem_prime_vunmap(obj, vaddr); } EXPORT_SYMBOL(drm_gem_dmabuf_vunmap); -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/2] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails
On Mon, Apr 23, 2018 at 5:06 PM, John Stultz wrote: > If the gl precompositor isn't being used, we cannot accept > every layer as a device composited layer. > > Thus this patch adds some extra logic in the validate function > to try to map layers to available device planes, falling back > to client side compositing if we run-out of planes. > > Credit to Rob Herring, who's work this single plane patch was > originally based on. > > Feedback or alternative ideas would be greatly appreciated! > > Cc: Marissa Wall > Cc: Sean Paul > Cc: Dmitry Shmidt > Cc: Robert Foss > Cc: Matt Szczesiak > Cc: Liviu Dudau > Cc: David Hanna > Cc: Rob Herring > Cc: Alexandru-Cosmin Gheorghe > Cc: Alistair Strachan > Signed-off-by: John Stultz > Signed-off-by: John Stultz A patch so nice, I signed it off twice! :P Sorry, looks like I yanked and pasted one too many lines from the cc list. -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 1/2] drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag
The drm_hwcomposer has its own GL pre-compositor which is used to squish layers when there are more layers then planes on the display hardware. In many ways this duplicates the client-side GL compositing that is done in SurfaceFlinger, but in theory can be more highly optimized for the hardware. Unfortunately, due to these optimizations, the drm_hwcomposer's pre-compositor becomes somewhat hardware specific (originally targeting nvidia hardware, I believe). So on some hardware, the gl precompositor may not actually initialize due to hardware missing features, or the hardware supporting different shader APIs. Rather then try to rework the drm_hwcomposers precompositor to be more generic, I instead suggest that when the precompositor fails to initialize, we simply fall back to the already more widely compatible client compositor in SurfaceFlinger. Thus, this patch cleans up some of the precompositor initialization, which didn't handle failures well. Feedback or alternative ideas would be greatly appreciated! Cc: Marissa Wall Cc: Sean Paul Cc: Dmitry Shmidt Cc: Robert Foss Cc: Matt Szczesiak Cc: Liviu Dudau Cc: David Hanna Cc: Rob Herring Cc: Alexandru-Cosmin Gheorghe Cc: Alistair Strachan Signed-off-by: John Stultz --- drmdisplaycompositor.cpp | 40 +--- drmdisplaycompositor.h | 3 +++ 2 files changed, 24 insertions(+), 19 deletions(-) diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp index e556e86..5c6bf9b 100644 --- a/drmdisplaycompositor.cpp +++ b/drmdisplaycompositor.cpp @@ -222,6 +222,13 @@ int DrmDisplayCompositor::Init(DrmResources *drm, int display) { return ret; } + pre_compositor_.reset(new GLWorkerCompositor()); + ret = pre_compositor_->Init(); + if (ret) { +ALOGE("Failed to initialize OpenGL compositor %d", ret); +pre_compositor_.reset(); + } + initialized_ = true; return 0; } @@ -294,14 +301,16 @@ int DrmDisplayCompositor::ApplySquash(DrmDisplayComposition *display_comp) { } std::vector ®ions = display_comp->squash_regions(); - ret = pre_compositor_->Composite(display_comp->layers().data(), + if (pre_compositor_) { +ret = pre_compositor_->Composite(display_comp->layers().data(), regions.data(), regions.size(), fb.buffer(), display_comp->importer()); - pre_compositor_->Finish(); +pre_compositor_->Finish(); - if (ret) { -ALOGE("Failed to squash layers"); -return ret; +if (ret) { + ALOGE("Failed to squash layers"); + return ret; +} } ret = display_comp->CreateNextTimelineFence(); @@ -328,14 +337,16 @@ int DrmDisplayCompositor::ApplyPreComposite( } std::vector ®ions = display_comp->pre_comp_regions(); - ret = pre_compositor_->Composite(display_comp->layers().data(), + if (pre_compositor_) { +ret = pre_compositor_->Composite(display_comp->layers().data(), regions.data(), regions.size(), fb.buffer(), display_comp->importer()); - pre_compositor_->Finish(); +pre_compositor_->Finish(); - if (ret) { -ALOGE("Failed to pre-composite layers"); -return ret; +if (ret) { + ALOGE("Failed to pre-composite layers"); + return ret; +} } ret = display_comp->CreateNextTimelineFence(); @@ -395,15 +406,6 @@ int DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) { std::vector &pre_comp_regions = display_comp->pre_comp_regions(); - if (!pre_compositor_) { -pre_compositor_.reset(new GLWorkerCompositor()); -int ret = pre_compositor_->Init(); -if (ret) { - ALOGE("Failed to initialize OpenGL compositor %d", ret); - return ret; -} - } - int squash_layer_index = -1; if (squash_regions.size() > 0) { squash_framebuffer_index_ = (squash_framebuffer_index_ + 1) % 2; diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h index f1965fb..ed6c5f9 100644 --- a/drmdisplaycompositor.h +++ b/drmdisplaycompositor.h @@ -98,6 +98,9 @@ class DrmDisplayCompositor { return &squash_state_; } + bool uses_GL() { +return !!pre_compositor_; + } private: struct ModeState { bool needs_modeset = false; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 2/2] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails
If the gl precompositor isn't being used, we cannot accept every layer as a device composited layer. Thus this patch adds some extra logic in the validate function to try to map layers to available device planes, falling back to client side compositing if we run-out of planes. Credit to Rob Herring, who's work this single plane patch was originally based on. Feedback or alternative ideas would be greatly appreciated! Cc: Marissa Wall Cc: Sean Paul Cc: Dmitry Shmidt Cc: Robert Foss Cc: Matt Szczesiak Cc: Liviu Dudau Cc: David Hanna Cc: Rob Herring Cc: Alexandru-Cosmin Gheorghe Cc: Alistair Strachan Signed-off-by: John Stultz Signed-off-by: John Stultz --- drmhwctwo.cpp | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp index dfca1a6..437a439 100644 --- a/drmhwctwo.cpp +++ b/drmhwctwo.cpp @@ -686,6 +686,15 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types, supported(__func__); *num_types = 0; *num_requests = 0; + int avail_planes = primary_planes_.size() + overlay_planes_.size(); + + /* + * If more layers then planes, save one plane + * for client composited layers + */ + if (avail_planes < layers_.size()) + avail_planes--; + for (std::pair &l : layers_) { DrmHwcTwo::HwcLayer &layer = l.second; switch (layer.sf_type()) { @@ -695,6 +704,15 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types, layer.set_validated_type(HWC2::Composition::Client); ++*num_types; break; + case HWC2::Composition::Device: +if (!compositor_.uses_GL() && !avail_planes) { + layer.set_validated_type(HWC2::Composition::Client); + ++*num_types; + break; +} else { + avail_planes--; + } + /* fall through */ default: layer.set_validated_type(layer.sf_type()); break; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Intel: Add a Kaby Lake PCI ID
From: Matt Atwood Signed-off-by: Matt Atwood --- intel/intel_chipset.h | 1 + 1 file changed, 1 insertion(+) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 01d250e..6b8fd1d 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -203,6 +203,7 @@ #define PCI_CHIP_KABYLAKE_ULX_GT2 0x591E #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 #define PCI_CHIP_KABYLAKE_M_GT20x5917 +#define PCI_CHIP_KABYLAKE_M_GT20x591C #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: track dma-buf fences
Hi Emre, Sorry for the late reply. On Wednesday, 4 April 2018 14:03:57 EEST Emre Ucan wrote: > We have to check dma-buf reservation objects > of our framebuffers before we use them. > Otherwise, another driver might be writing > on the same buffer which we are using. > This would cause visible tearing effects > on display. > > We can use existing atomic helper functions > to solve this problem. I've always found the 72 columns limit in commit messages to be quite limiting, especially for the subject line. Out of curiosity, is there any specific reason why you limit it further ? > v2 changes: > - Remove drm_atomic_helper_wait_for_fences() > call in rcar_du_kms.c. The commit_tail() > function in drm_atomic_helper.c, which calls > our atomic_commit_tail() implementation, > already calls it. > - Remove proposed rcar_du_vsp_set_fence_for_plane() > function. Call drm_gem_fb_prepare_fb(), which > calls drm_atomic_set_fence_for_plane(). > > Signed-off-by: Emre Ucan > --- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 2c260c3..fbad616 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include Nitpicking, could you please keep the headers alphabetically sorted ? It helps locating duplicates quickly. > #include > #include > @@ -237,7 +238,7 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane > *plane, } > } > > - return 0; > + return drm_gem_fb_prepare_fb(plane, state); If drm_gem_fb_prepare_fb() fails we need to clean up the operations performed earlier in this function. I think the following would be enough. ret = drm_gem_fb_prepare_fb(plane, state); if (ret) goto fail; return 0; Could you please test this ? > fail: > while (i--) { -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91808] trine1 misrender r600g
https://bugs.freedesktop.org/show_bug.cgi?id=91808 --- Comment #11 from Dave Airlie --- Created attachment 139029 --> https://bugs.freedesktop.org/attachment.cgi?id=139029&action=edit attempted fix -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC for a render API to support adaptive sync and VRR
On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote: > On 2018-04-20 04:32 PM, Manasi Navare wrote: > > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: > >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: > >>> Michel Dänzer writes: > Time-based presentation seems to be the right approach for preventing > micro-stutter in games as well, Croteam developers have been researching > this. > >>> > >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present > >>> extension offer the ability to specify the desired display time in > >>> seconds. > >>> > >>> Similarly, I'd suggest that the min/max display refresh rate values be > >>> advertised as time between frames rather than frames per second. > > > > So there is a global min and max refresh rate as advertised by the monitor > > range descriptor. That I guess can be exposed as a global range in terms of > > min and max time between frames as a global property of the connector. > > > > We dont need the per mode min and max refresh rate to be exposed right? > > If I understand VRR right, with CinemaVRR acceptable refresh rates might fall > outside the range advertised by the monitor. Would we > 1) advertise 24/1.001 as a lower bound, > 2) expect media apps to use the lower bound simply for informational > purposes, > 3) or simply not support CinemaVRR? > > (1) has the added caveat that not all reported rates would be supported. > > Alternatively a bit could indicate that CinemaVRR is support, but I'm not > sure if user mode would need all these details. > > Harry Are there special CinemaVRR suported monitors? In that case we need to understand how those monitors advertise the monitor range and if they have a bit in EDID that indicate they are CinemaVRR capable as opposed to just the Adaptive Sync/VRR. Harry, if you have one of those monitors, could you send the EDID dump for that? Manasi > > > > >>> > >>> I'd also encourage using a single unit for all of these values, > >>> preferably nanoseconds. Absolute times should all be referenced to > >>> CLOCK_MONOTONIC. > >> > >> +1 on everything Keith said. I got somehow dragged in khr vk > >> discussions around preventing micro-stuttering, and consensus seems to > >> be that timestamps for scheduling frames is the way to go, most likely > >> absolute ones (not everything is running Linux unfortunately, so can't > >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC). > >> -Daniel > > > > And yes I also got consensus from Mesa and media folks about using the > > absolute timestamp for scheduling the frames and then the driver will > > modify the vblank logic to "present no earlier than the timestamp" > > > > Manasi > > > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ > > 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 8/8] drm: connector: Remove DRM_BUS_FLAG_DATA_* flags
Hi Jacopo, Thank you for the patch. On Thursday, 19 April 2018 12:31:09 EEST Jacopo Mondi wrote: > DRM_BUS_FLAG_DATA_* flags, defined in drm_connector.h header file are > used to swap ordering of LVDS RGB format to accommodate DRM objects > that need to handle LVDS components ordering. > > Now that the only 2 users of DRM_BUS_FLAG_DATA_* flags have been ported > to use the newly introduced MEDIA_BUS_FMT_RGB888_1X7X*_LE media bus > formats, remove them. I'm not opposed to this (despite my review of patch 5/8), but I think the _LE suffix isn't the right name for the new formats. _BE and _LE relate to byte swapping, while here you really need to describe full mirroring. Maybe a _MIRROR variant would be more appropriate ? > Signed-off-by: Jacopo Mondi > --- > include/drm/drm_connector.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index 675cc3f..9e0d6d5 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -286,10 +286,6 @@ struct drm_display_info { > #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) > /* drive data on neg. edge */ > #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3) > -/* data is transmitted MSB to LSB on the bus */ > -#define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4) > -/* data is transmitted LSB to MSB on the bus */ > -#define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5) > > /** >* @bus_flags: Additional information (like pixel signal polarity) for -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106196] GPU randomly hangs while playing game Rise of the Tomb Rider
https://bugs.freedesktop.org/show_bug.cgi?id=106196 Bug ID: 106196 Summary: GPU randomly hangs while playing game Rise of the Tomb Rider Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 139028 --> https://bugs.freedesktop.org/attachment.cgi?id=139028&action=edit dmesg * Fedora 28 - https://download.fedoraproject.org/pub/fedora/linux/releases/test/28_Beta/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-28_Beta-1.3.iso * Latest system updates: - kernel 4.16.3 - mesa 18.0.1 - llvm 6.0.0 * Steam client version 1523923735 For reproduction issue: 1) Play in game several hours until GPU hang occurs Symptoms: 1. The system stop to respod. 2. All the LEDs on the video card showing the load start to glow. 3. The turbine on the video card starts to make a lot of noise. kernel output after GPU hang: [10918.342576] amdgpu :07:00.0: [gfxhub] VMC page fault (src_id:0 ring:158 vmid:7 pas_id:0) [10918.342582] amdgpu :07:00.0: at page 0x1891a90f from 27 [10918.342585] amdgpu :07:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x0070113D [10918.342591] amdgpu :07:00.0: [gfxhub] VMC page fault (src_id:0 ring:158 vmid:7 pas_id:0) [10918.342594] amdgpu :07:00.0: at page 0x1891a90f from 27 [10918.342597] amdgpu :07:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [10928.687661] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=1874360, last emitted seq=1874362 [10928.687666] [drm] No hardware hang detected. Did some blocks stall? [11016.291301] sysrq: SysRq : Show Blocked State [11016.291315] taskPC stack pid father [11016.291509] XwaylandD10616 1956 1882 0x0004 [11016.291522] Call Trace: [11016.291541] ? __schedule+0x2bd/0xb00 [11016.291555] ? dma_fence_wait_any_timeout+0x264/0x2f0 [11016.291564] schedule+0x2f/0x90 [11016.291573] schedule_timeout+0x35c/0x520 [11016.291592] ? dma_fence_wait_any_timeout+0x264/0x2f0 [11016.291602] dma_fence_wait_any_timeout+0x230/0x2f0 [11016.291734] amdgpu_sa_bo_new+0x444/0x510 [amdgpu] [11016.291900] amdgpu_ib_get+0x31/0x90 [amdgpu] [11016.292048] amdgpu_job_alloc_with_ib+0x46/0x80 [amdgpu] [11016.292128] amdgpu_map_buffer.isra.10+0xa3/0x1f0 [amdgpu] [11016.292215] amdgpu_ttm_copy_mem_to_mem+0x3c6/0x5d0 [amdgpu] [11016.292305] ? amdgpu_vm_bo_invalidate+0x3b/0x210 [amdgpu] [11016.292385] amdgpu_move_blit.constprop.13+0x82/0x110 [amdgpu] [11016.292467] amdgpu_bo_move+0x94/0x1c0 [amdgpu] [11016.292486] ttm_bo_handle_move_mem+0x10d/0x540 [ttm] [11016.292509] ? ttm_bo_evict+0x155/0x1e0 [ttm] [11016.292530] ? mutex_trylock+0xcd/0xe0 [11016.292552] ? ttm_mem_evict_first+0x1cf/0x260 [ttm] [11016.292574] ? ttm_bo_mem_space+0x2da/0x4a0 [ttm] [11016.292599] ? ttm_bo_validate+0xe3/0x1a0 [ttm] [11016.292612] ? ttm_bo_init_reserved+0x40e/0x470 [ttm] [11016.292628] ? mutex_trylock+0xcd/0xe0 [11016.292645] ? ttm_bo_init_reserved+0x42a/0x470 [ttm] [11016.292723] ? amdgpu_bo_do_create+0x1da/0x570 [amdgpu] [11016.292799] ? amdgpu_fill_buffer+0x320/0x320 [amdgpu] [11016.292885] ? amdgpu_bo_create+0x4f/0x2c0 [amdgpu] [11016.292993] ? amdgpu_gem_object_create+0x80/0x110 [amdgpu] [11016.293075] ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu] [11016.293153] ? amdgpu_gem_create_ioctl+0x1eb/0x2a0 [amdgpu] [11016.293165] ? __might_fault+0x3e/0x90 [11016.293244] ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu] [11016.293277] ? drm_ioctl_kernel+0x5b/0xb0 [drm] [11016.293308] ? drm_ioctl+0x1c0/0x380 [drm] [11016.293417] ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu] [11016.293529] ? amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [11016.293544] ? do_vfs_ioctl+0xa5/0x6d0 [11016.293559] ? SyS_ioctl+0x74/0x80 [11016.293574] ? do_syscall_64+0x79/0x210 [11016.293584] ? entry_SYSCALL_64_after_hwframe+0x42/0xb7 [11016.294195] kworker/u16:2 D12472 10521 2 0x8000 [11016.294228] Workqueue: events_unbound commit_work [drm_kms_helper] [11016.294237] Call Trace: [11016.294252] ? __schedule+0x2bd/0xb00 [11016.294266] ? dma_fence_default_wait+0x231/0x370 [11016.294278] schedule+0x2f/0x90 [11016.294288] schedule_timeout+0x35c/0x520 [11016.294301] ? dma_fence_default_wait+0x72/0x370 [11016.294316] ? dma_fence_default_wait+0x231/0x370 [11016.294325] dma_fence_default_wait+0x25d/0x370 [11016.294334] ? dma_fence_release+0x160/0x160 [11016.294347] dma_fence_wait_timeout+0x4f/0x270 [11016.294358] reservation_object_wait_timeout_rcu+0x236/0x4e0 [11016.294485] amdgpu_dm_do_flip+0x112/0x360 [amdgpu] [11016.294624] amdgpu_dm_atomic_commit_tail+0xac7/0xda0 [amdgpu] [11016.294640] ? wait_for_completion_timeout+0x73/0x1a0 [11016.294673] commit_tail+0x3d/0x70 [drm_kms_h
Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
On Monday, 23 April 2018 23:09:55 EEST Mauro Carvalho Chehab wrote: > Laurent Pinchart escreveu: > > On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote: > > > Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu: > > > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote: > > > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote: > > > >>> Add stubs for omapfb_dss.h, in the case it is included by > > > >>> some driver when CONFIG_FB_OMAP2 is not defined, with can > > > >>> happen on ARM when DRM_OMAP is not 'n'. > > > >>> > > > >>> That allows building such driver(s) with COMPILE_TEST. > > > >>> > > > >>> Signed-off-by: Mauro Carvalho Chehab > > > >> > > > >> This patch should be dropped (together with patch #6/7) as it was > > > >> superseded by a better solution suggested by Laurent: > > > >> > > > >> https://patchwork.kernel.org/patch/10325193/ > > > >> > > > >> ACK-ed by Tomi: > > > >> > > > >> https://www.spinics.net/lists/dri-devel/msg171918.html > > > >> > > > >> and already merged by you (commit 7378f1149884 "media: omap2: > > > >> omapfb: allow building it with COMPILE_TEST").. > > > > > > > > Hmm, I see now while this patch is still included: > > > > > > > > menuconfig FB_OMAP2 > > > > > > > > tristate "OMAP2+ frame buffer support" > > > > depends on FB > > > > depends on DRM_OMAP = n > > > > > > > > Ideally we should be able to build both drivers in the same kernel > > > > (especially as modules). > > > > > > > > I was hoping that it could be fixed easily but then I discovered > > > > the root source of the problem: > > > > > > > > drivers/gpu/drm/omapdrm/dss/display.o: In function > > > > `omapdss_unregister_display': display.c:(.text+0x2c): multiple > > > > definition > > > > of `omapdss_unregister_display' > > > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198) > > > > : > > > > first defined here ... > > > > > > Yes, and declared on two different places: > > > > > > drivers/gpu/drm/omapdrm/dss/omapdss.h:void > > > omapdss_unregister_display(struct omap_dss_device *dssdev); > > > include/video/omapfb_dss.h:void > > > omapdss_unregister_display(struct omap_dss_device *dssdev); > > > > > > one alternative would be to give different names to it, and a common > > > header for both. > > > > > > At such header, it could be doing something like: > > > > > > static inline void omapdss_unregister_display(struct omap_dss_device > > > *dssdev) { > > > #if enabled(CONFIG_DRM_OMAP) > > > > > > omapdss_unregister_display_drm(struct omap_dss_device *dssdev); > > > > > > #else > > > > > > omapdss_unregister_display_fb(struct omap_dss_device *dssdev); > > > > > > ##endif > > > } > > > > > > Yet, after a very quick check, it seems that nowadays only the > > > media omap driver uses the symbols at FB_OMAP: > > > > > > $ git grep omapfb_dss.h > > > drivers/media/platform/omap/omap_vout.c:#include > > > drivers/media/platform/omap/omap_voutdef.h:#include > > > drivers/media/platform/omap/omap_voutlib.c:#include > > > > > > So, perhaps just renaming the common symbols and changing FB_OMAP2 to: > > > menuconfig FB_OMAP2 > > > > > >tristate "OMAP2+ frame buffer support" > > >depends on FB > > >depends on (DRM_OMAP = n) || COMPILE_TEST > > > > > > would be enough to allow to build both on ARM. > > > > I don't think it's worth it renaming the common symbols. They will change > > over time as omapdrm is under heavy rework, and it's painful enough > > without having to handle cross-tree changes. > > It could just rename the namespace-conflicting FB_OMAP2 functions, > keeping the DRM ones as-is. > > > Let's just live with the fact that both drivers > > can't be compiled at the same time, given that omapfb is deprecated. > > IMO, a driver that it is deprecated, being in a state where it > conflicts with a non-deprecated driver that is under heavy rework > is a very good candidate to go to drivers/staging or even to /dev/null. It's on its way, but slowly as we need to take userspace into account. Tomi should have more insight on a possible schedule for removal of omapfb. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=100105 --- Comment #5 from Jan Vesely --- (In reply to Jan Vesely from comment #4) > Lowering CL requirements combined with the following pull requests: > https://github.com/Theano/libgpuarray/pull/571 > https://github.com/Theano/libgpuarray/pull/570 Both above pull requests have been merged with slight modifications. running CLOVER_DEVICE_VERSION_OVERRIDE=1.2 CLOVER_DEVICE_CLC_VERSION_OVERRIDE=1.2 results in: Ran 6670 tests in 991.622s OK (SKIP=12) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
Hi Mauro, On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote: > Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu: > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote: > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote: > >>> Add stubs for omapfb_dss.h, in the case it is included by > >>> some driver when CONFIG_FB_OMAP2 is not defined, with can > >>> happen on ARM when DRM_OMAP is not 'n'. > >>> > >>> That allows building such driver(s) with COMPILE_TEST. > >>> > >>> Signed-off-by: Mauro Carvalho Chehab > >> > >> This patch should be dropped (together with patch #6/7) as it was > >> superseded by a better solution suggested by Laurent: > >> > >> https://patchwork.kernel.org/patch/10325193/ > >> > >> ACK-ed by Tomi: > >> > >> https://www.spinics.net/lists/dri-devel/msg171918.html > >> > >> and already merged by you (commit 7378f1149884 "media: omap2: > >> omapfb: allow building it with COMPILE_TEST").. > > > > Hmm, I see now while this patch is still included: > > > > menuconfig FB_OMAP2 > > tristate "OMAP2+ frame buffer support" > > depends on FB > > depends on DRM_OMAP = n > > > > Ideally we should be able to build both drivers in the same kernel > > (especially as modules). > > > > I was hoping that it could be fixed easily but then I discovered > > the root source of the problem: > > > > drivers/gpu/drm/omapdrm/dss/display.o: In function > > `omapdss_unregister_display': display.c:(.text+0x2c): multiple definition > > of `omapdss_unregister_display' > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): > > first defined here ... > > Yes, and declared on two different places: > > drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct > omap_dss_device *dssdev); include/video/omapfb_dss.h:void > omapdss_unregister_display(struct omap_dss_device *dssdev); > > one alternative would be to give different names to it, and a common > header for both. > > At such header, it could be doing something like: > > static inline void omapdss_unregister_display(struct omap_dss_device > *dssdev) { > #if enabled(CONFIG_DRM_OMAP) > omapdss_unregister_display_drm(struct omap_dss_device *dssdev); > #else > omapdss_unregister_display_fb(struct omap_dss_device *dssdev); > ##endif > } > > Yet, after a very quick check, it seems that nowadays only the > media omap driver uses the symbols at FB_OMAP: > > $ git grep omapfb_dss.h > drivers/media/platform/omap/omap_vout.c:#include > drivers/media/platform/omap/omap_voutdef.h:#include > drivers/media/platform/omap/omap_voutlib.c:#include > > So, perhaps just renaming the common symbols and changing FB_OMAP2 to: > > menuconfig FB_OMAP2 >tristate "OMAP2+ frame buffer support" >depends on FB >depends on (DRM_OMAP = n) || COMPILE_TEST > > would be enough to allow to build both on ARM. I don't think it's worth it renaming the common symbols. They will change over time as omapdrm is under heavy rework, and it's painful enough without having to handle cross-tree changes. Let's just live with the fact that both drivers can't be compiled at the same time, given that omapfb is deprecated. > > I need some more time to think about this.. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=105729 --- Comment #7 from Jan Vlug --- Created attachment 139027 --> https://bugs.freedesktop.org/attachment.cgi?id=139027&action=edit dmesg Requested dmesg. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=105729 --- Comment #6 from Jan Vlug --- Created attachment 139026 --> https://bugs.freedesktop.org/attachment.cgi?id=139026&action=edit glxinfo Requested glxinfo. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=105729 --- Comment #5 from Jan Vlug --- Sorry for my late reply. The interesting thing is that the flickering did not occur any more since comment 4 was added. I was waiting for the flickering to occur again before posting the requested info, but it did not until now, so I will attach the requested info while the flickering is not manifest. My current versions are: Graphics: Card: Advanced Micro Devices [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/560] Display Server: X.org 1.19.6 drivers: modesetting,fbdev,vesa tty size: 166x42 Advanced Data: N/A for root Linux nyx 4.15.17-300.fc27.x86_64 #1 SMP Thu Apr 12 18:19:17 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: drm: fsl-dcu: Update to NXP email address
Hi Stefan, On Fri, Mar 30, 2018 at 2:10 PM, Fabio Estevam wrote: > From: Fabio Estevam > > The freescale.com domain will stop working soon, so use > the nxp.com domain instead. > > Signed-off-by: Fabio Estevam > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4923621..794c130 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4661,7 +4661,7 @@ F: > Documentation/devicetree/bindings/display/exynos/ > > DRM DRIVERS FOR FREESCALE DCU > M: Stefan Agner > -M: Alison Wang > +M: Alison Wang A gentle ping... ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/vc4: Add parameter for syncobj support
Stefan Schake writes: > This allows runtime detection of syncobj submission support. > > Signed-off-by: Stefan Schake I think if we move patch 1 after 2+3, then we can just drop this one and use drmGetCap(fd, DRM_CAP_SYNCOBJ, &value) in userspace for detection. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/vc4: Export fence through syncobj
Stefan Schake writes: > Allow specifying a syncobj on render job submission where we store the > fence for the job. This gives userland flexible access to the fence. > > Signed-off-by: Stefan Schake > --- > drivers/gpu/drm/vc4/vc4_gem.c | 38 +++--- > include/uapi/drm/vc4_drm.h| 13 + > 2 files changed, 48 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c > index 232363488125..b39515a4ddcb 100644 > --- a/drivers/gpu/drm/vc4/vc4_gem.c > +++ b/drivers/gpu/drm/vc4/vc4_gem.c > @@ -656,7 +656,8 @@ vc4_lock_bo_reservations(struct drm_device *dev, > */ > static int > vc4_queue_submit(struct drm_device *dev, struct vc4_exec_info *exec, > - struct ww_acquire_ctx *acquire_ctx) > + struct ww_acquire_ctx *acquire_ctx, > + struct drm_syncobj *out_sync) > { > struct vc4_dev *vc4 = to_vc4_dev(dev); > struct vc4_exec_info *renderjob; > @@ -679,6 +680,9 @@ vc4_queue_submit(struct drm_device *dev, struct > vc4_exec_info *exec, > fence->seqno = exec->seqno; > exec->fence = &fence->base; > > + if (out_sync) > + drm_syncobj_replace_fence(out_sync, exec->fence); > + > vc4_update_bo_seqnos(exec, seqno); > > vc4_unlock_bo_reservations(dev, exec, acquire_ctx); > @@ -1114,6 +1118,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data, > struct vc4_dev *vc4 = to_vc4_dev(dev); > struct vc4_file *vc4file = file_priv->driver_priv; > struct drm_vc4_submit_cl *args = data; > + struct drm_syncobj *out_sync = NULL; > struct vc4_exec_info *exec; > struct ww_acquire_ctx acquire_ctx; > struct dma_fence *in_fence; > @@ -1123,11 +1128,17 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void > *data, >VC4_SUBMIT_CL_FIXED_RCL_ORDER | >VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X | >VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y | > - VC4_SUBMIT_CL_IMPORT_SYNCOBJ)) != 0) { > + VC4_SUBMIT_CL_IMPORT_SYNCOBJ | > + VC4_SUBMIT_CL_EXPORT_SYNCOBJ)) != 0) { > DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags); > return -EINVAL; > } > > + if (args->pad2 != 0) { > + DRM_DEBUG("->pad2 must be set to zero\n"); > + return -EINVAL; > + } > + > exec = kcalloc(1, sizeof(*exec), GFP_KERNEL); > if (!exec) { > DRM_ERROR("malloc failure on exec struct\n"); > @@ -1202,12 +1213,33 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void > *data, > if (ret) > goto fail; > > + if (args->flags & VC4_SUBMIT_CL_EXPORT_SYNCOBJ) { > + out_sync = drm_syncobj_find(file_priv, args->out_sync); > + if (!out_sync) { > + ret = -EINVAL; > + goto fail; > + } > + > + /* We replace the fence in out_sync in vc4_queue_submit since > + * the render job could execute immediately after that call. > + * If it finishes before our ioctl processing resumes the > + * render job fence could already have been freed. > + */ > + } Same comment about not needing the exec flag. > + > /* Clear this out of the struct we'll be putting in the queue, >* since it's part of our stack. >*/ > exec->args = NULL; > > - ret = vc4_queue_submit(dev, exec, &acquire_ctx); > + ret = vc4_queue_submit(dev, exec, &acquire_ctx, out_sync); > + > + /* The syncobj isn't part of the exec data and we need to free our > + * reference even if job submission failed. > + */ > + if (out_sync) > + drm_syncobj_put(out_sync); > + > if (ret) > goto fail; > > diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h > index 389f21931c25..3a2ef9b5b60b 100644 > --- a/include/uapi/drm/vc4_drm.h > +++ b/include/uapi/drm/vc4_drm.h > @@ -174,6 +174,7 @@ struct drm_vc4_submit_cl { > #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X (1 << 2) > #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y (1 << 3) > #define VC4_SUBMIT_CL_IMPORT_SYNCOBJ (1 << 4) > +#define VC4_SUBMIT_CL_EXPORT_SYNCOBJ (1 << 5) > __u32 flags; > > /* Returned value of the seqno of this render job (for the > @@ -189,6 +190,18 @@ struct drm_vc4_submit_cl { >* syncobj is signalled. >*/ > __u32 in_sync; > + > + /* Syncobj handle to export fence to. Set together with EXPORT_SYNCOBJ > + * flag. If set, the fence in the syncobj will be replaced with a fence > + * that signals upon completion of this render job. > + */ > + __u32 out_sync; > + > + /* Unused field to align this struct on 64 bits. Must be set to 0. > + * If one ever need
Re: [PATCH 2/4] drm/vc4: Syncobj import support
Stefan Schake writes: > Allow userland to specify a syncobj that is waited on before a render job > starts processing. > > Signed-off-by: Stefan Schake > --- > drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ > drivers/gpu/drm/vc4/vc4_gem.c | 33 +++-- > include/uapi/drm/vc4_drm.h| 9 + > 3 files changed, 34 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h > index 4288615b66a2..3105df99cb12 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.h > +++ b/drivers/gpu/drm/vc4/vc4_drv.h > @@ -10,6 +10,8 @@ > #include > #include > #include > +#include > + Drop the extra \n? > #include "uapi/drm/vc4_drm.h" > > diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c > index 2107b0daf8ef..232363488125 100644 > --- a/drivers/gpu/drm/vc4/vc4_gem.c > +++ b/drivers/gpu/drm/vc4/vc4_gem.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > > #include "uapi/drm/vc4_drm.h" > #include "vc4_drv.h" > @@ -1115,21 +1116,18 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void > *data, > struct drm_vc4_submit_cl *args = data; > struct vc4_exec_info *exec; > struct ww_acquire_ctx acquire_ctx; > + struct dma_fence *in_fence; > int ret = 0; > > if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR | >VC4_SUBMIT_CL_FIXED_RCL_ORDER | >VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X | > - VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y)) != 0) { > + VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y | > + VC4_SUBMIT_CL_IMPORT_SYNCOBJ)) != 0) { > DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags); > return -EINVAL; > } > > - if (args->pad2 != 0) { > - DRM_DEBUG("->pad2 must be set to zero\n"); > - return -EINVAL; > - } > - > exec = kcalloc(1, sizeof(*exec), GFP_KERNEL); > if (!exec) { > DRM_ERROR("malloc failure on exec struct\n"); > @@ -1164,6 +1162,29 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data, > } > } > > + if (args->flags & VC4_SUBMIT_CL_IMPORT_SYNCOBJ) { > + ret = drm_syncobj_find_fence(file_priv, args->in_sync, > + &in_fence); > + if (ret) > + goto fail; > + > + /* When the fence (or fence array) is exclusively from our > + * context we can skip the wait since jobs are executed in > + * order of their submission through this ioctl and this can > + * only have fences from a prior job. > + */ > + if (!dma_fence_match_context(in_fence, > + vc4->dma_fence_context)) { > + ret = dma_fence_wait(in_fence, true); > + if (ret) { > + dma_fence_put(in_fence); > + goto fail; > + } > + } > + > + dma_fence_put(in_fence); > + } I don't think we need an extra flag here. 0 is an invalid syncobj handle, so that could be the indication that there's no input syncobj. Long term, we should probably only block once we're ready to exec the job, not at submit time. However, I think we can wait on fixing that until we start using the GPU scheduler. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/vc4: Add CTM support
Stefan Schake writes: > The hardware has a single block for applying a CTM prior to gamma lut. > It can be fed with pixels from one of our CRTC at a time and uses a > matrix with S0.9 scalars. Use private atomic state to reject attempts > from userland to apply CTM for more than one CRTC at a time and reject > matrices with scalars that we can't approximate without integer bits. Looks good! I think you got all the transition cases we were concerned about before. Reviewed and applied these two to drm-misc-next. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default
https://bugs.freedesktop.org/show_bug.cgi?id=106006 --- Comment #12 from Joel Sass --- Created attachment 139022 --> https://bugs.freedesktop.org/attachment.cgi?id=139022&action=edit I don't think this is the same file from 2.17. Sorry. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default
https://bugs.freedesktop.org/show_bug.cgi?id=106006 --- Comment #11 from Joel Sass --- Okay, sadly, I wasn't clear about the kernel I was running. It's located here: https://github.com/M-Bab/linux-kernel-amdgpu and I installed the .deb created by the git contributor here: https://github.com/M-Bab/linux-kernel-amdgpu-binaries I downloaded the source listed in the first link I posted above, and it doesn't appear to have the same file structure you'd listed in your patch. I've attached amdgpu_dm_color.c to this bug. If you don't want to patch for this, I understand. I can see if I can speak to the person responsible for this repo. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/vc4: Add support for plane alpha
Stefan Schake writes: > The HVS supports mixing fixed alpha with per-pixel alpha or > setting a fixed plane alpha in case there is no per-pixel information. > This allows us to support the generic DRM plane alpha property. > > Signed-off-by: Stefan Schake Applied to drm-misc-next. Thanks! > @@ -565,6 +567,13 @@ static int vc4_plane_mode_set(struct drm_plane *plane, > SCALER_POS1_SCL_HEIGHT)); > } > > + /* Don't waste cycles mixing with plane alpha if the set alpha > + * is opaque or there is no per-pixel alpha information. > + * In any case we use the alpha property value as the fixed alpha. > + */ > + mix_plane_alpha = state->alpha != DRM_BLEND_ALPHA_OPAQUE && > + fb->format->has_alpha; > + > /* Position Word 2: Source Image Size, Alpha */ > vc4_state->pos2_offset = vc4_state->dlist_count; > vc4_dlist_write(vc4_state, > @@ -572,6 +581,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, > SCALER_POS2_ALPHA_MODE_PIPELINE : > SCALER_POS2_ALPHA_MODE_FIXED, > SCALER_POS2_ALPHA_MODE) | > + (mix_plane_alpha ? SCALER_POS2_ALPHA_MIX : 0) | > (fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) > | > VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) | > VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT)); In an interesting note from the docs, if you'd set SCALER_POS2_ALPHA_MIX with SCALER_POS2_ALPHA_MODE_FIXED, you'd get the fixed alpha squared! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/61] gpu: drm: vc4: simplify getting .drvdata
Wolfram Sang writes: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Applied to drm-misc-next. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/8] dt-bindings: display: atmel: optional video-interface of endpoints
On Mon, 23 Apr 2018 09:22:55 +0200 Peter Rosin wrote: > With bus-type/bus-width properties in the endpoint nodes, the video- > interface of the connection can be specified for cases where the > heuristic fails to select the correct output mode. This can happen > e.g. if not all RGB pins are routed on the PCB; the driver has no > way of knowing this, and needs to be told explicitly. > > This is critical for the devices that have the "conflicting output > formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant > RGB bits move around depending on the selected output mode. For > devices that do not have the "conflicting output formats" issue > (SAMA5D2, SAMA5D4), this is completely irrelevant. > > Signed-off-by: Peter Rosin Acked-by: Boris Brezillon > --- > .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 26 > ++ > 1 file changed, 26 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt > b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt > index 82f2acb3d374..9de434a8f523 100644 > --- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt > +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt > @@ -15,6 +15,14 @@ Required children nodes: > to external devices using the OF graph reprensentation (see ../graph.txt). > At least one port node is required. > > +Optional properties in grandchild nodes: > + Any endpoint grandchild node may specify a desired video interface > + according to ../../media/video-interfaces.txt, specifically > + - bus-type: must be <0>. > + - bus-width: recognized values are <12>, <16>, <18> and <24>, and > + override any output mode selection heuristic, forcing "rgb444", > + "rgb565", "rgb666" and "rgb888" respectively. > + > Example: > > hlcdc: hlcdc@f003 { > @@ -50,3 +58,21 @@ Example: > #pwm-cells = <3>; > }; > }; > + > + > +Example 2: With a video interface override to force rgb565; as above > +but with these changes/additions: > + > + &hlcdc { > + hlcdc-display-controller { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>; > + > + port@0 { > + hlcdc_panel_output: endpoint@0 { > + bus-type = <0>; > + bus-width = <16>; > + }; > + }; > + }; > + }; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/8] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
On Mon, 23 Apr 2018 09:22:56 +0200 Peter Rosin wrote: > This beats the heuristic that the connector is involved in what format > should be output for cases where this fails. > > E.g. if there is a bridge that changes format between the encoder and the > connector, or if some of the RGB pins between the lcd controller and the > encoder are not routed on the PCB. > > This is critical for the devices that have the "conflicting output > formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant > RGB bits move around depending on the selected output mode. For > devices that do not have the "conflicting output formats" issue > (SAMA5D2, SAMA5D4), this is completely irrelevant. > > Signed-off-by: Peter Rosin Acked-by: Boris Brezillon > --- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 > +--- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 + > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 67 --- > 3 files changed, 111 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > index d73281095fac..c38a479ada98 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > @@ -226,6 +226,55 @@ static void atmel_hlcdc_crtc_atomic_enable(struct > drm_crtc *c, > #define ATMEL_HLCDC_RGB888_OUTPUTBIT(3) > #define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0) > > +static int atmel_hlcdc_connector_output_mode(struct drm_connector_state > *state) > +{ > + struct drm_connector *connector = state->connector; > + struct drm_display_info *info = &connector->display_info; > + struct drm_encoder *encoder; > + unsigned int supported_fmts = 0; > + int j; > + > + encoder = state->best_encoder; > + if (!encoder) > + encoder = connector->encoder; > + > + switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) { > + case 0: > + break; > + case MEDIA_BUS_FMT_RGB444_1X12: > + return ATMEL_HLCDC_RGB444_OUTPUT; > + case MEDIA_BUS_FMT_RGB565_1X16: > + return ATMEL_HLCDC_RGB565_OUTPUT; > + case MEDIA_BUS_FMT_RGB666_1X18: > + return ATMEL_HLCDC_RGB666_OUTPUT; > + case MEDIA_BUS_FMT_RGB888_1X24: > + return ATMEL_HLCDC_RGB888_OUTPUT; > + default: > + return -EINVAL; > + } > + > + for (j = 0; j < info->num_bus_formats; j++) { > + switch (info->bus_formats[j]) { > + case MEDIA_BUS_FMT_RGB444_1X12: > + supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT; > + break; > + case MEDIA_BUS_FMT_RGB565_1X16: > + supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT; > + break; > + case MEDIA_BUS_FMT_RGB666_1X18: > + supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT; > + break; > + case MEDIA_BUS_FMT_RGB888_1X24: > + supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT; > + break; > + default: > + break; > + } > + } > + > + return supported_fmts; > +} > + > static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state) > { > unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK; > @@ -238,31 +287,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct > drm_crtc_state *state) > crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc); > > for_each_new_connector_in_state(state->state, connector, cstate, i) { > - struct drm_display_info *info = &connector->display_info; > unsigned int supported_fmts = 0; > - int j; > > if (!cstate->crtc) > continue; > > - for (j = 0; j < info->num_bus_formats; j++) { > - switch (info->bus_formats[j]) { > - case MEDIA_BUS_FMT_RGB444_1X12: > - supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT; > - break; > - case MEDIA_BUS_FMT_RGB565_1X16: > - supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT; > - break; > - case MEDIA_BUS_FMT_RGB666_1X18: > - supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT; > - break; > - case MEDIA_BUS_FMT_RGB888_1X24: > - supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT; > - break; > - default: > - break; > - } > - } > + supported_fmts = atmel_hlcdc_connector_output_mode(cstate); > > if (crtc->dc->desc->conflicting_output_formats) > output_fmts &= s
[Bug 106194] AMDGPU RIP: dm_update_crtcs_state on kernel 4.17rc2
https://bugs.freedesktop.org/show_bug.cgi?id=106194 Kevin McCormack changed: What|Removed |Added Summary|AMD Fury X system freeze on |AMDGPU RIP: |kernel 4.17rc2 |dm_update_crtcs_state on ||kernel 4.17rc2 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5
https://bugzilla.kernel.org/show_bug.cgi?id=199101 --- Comment #22 from Kevin McCormack (wittyma...@yahoo.com) --- Flickering seems to be gone on 4.17rc2! However, there's a new issue :/ https://bugs.freedesktop.org/show_bug.cgi?id=106194 -- 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 106194] AMD Fury X system freeze on kernel 4.17rc2
https://bugs.freedesktop.org/show_bug.cgi?id=106194 Bug ID: 106194 Summary: AMD Fury X system freeze on kernel 4.17rc2 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: harlemsquir...@gmail.com Created attachment 139018 --> https://bugs.freedesktop.org/attachment.cgi?id=139018&action=edit dmesg output running kernel 4.17-rc2 I left my computer on over night. After I noticed the system was frozen just now, I rebooted to found these log entries. 5:06:46 AM RIP: dm_update_crtcs_state+0x347/0x3c0 [amdgpu] RSP: b2560bc37b10 5:06:46 AM kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4700! Software versions: OpenGL version string: 3.0 Mesa 18.0.1 CPU hardware: x86_64 AMD Ryzen 7 1800X Eight-Core Processor Max Speed: 4100 MHz Current Speed: 3600 MHz Memory: Speed: 3200 MT/s totalusedfree shared buff/cache available Mem: 15Gi 3.0Gi11Gi67Mi 1.5Gi12Gi Swap: 7.8Gi 0B 7.8Gi GPU hardware: OpenGL renderer string: AMD Radeon (TM) R9 Fury Series (FIJI / DRM 3.23.0 / 4.15.15-1-ARCH, LLVM 6.0.0) 0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] [1002:7300] (rev c8) 0c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] [1002:67df] (rev e7) Motherboard: ASUSTeK COMPUTER INC. CROSSHAIR VI HERO BIOS Version: 3008 Storage: Smart Log for NVME device:nvme0 namespace-id: I've attached the relevent dmesg output. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] drm/bridge: Add Cadence DSI driver
On Sat, 21 Apr 2018 09:08:45 +0200 Boris Brezillon wrote: > Add a driver for Cadence DPI -> DSI bridge. > > This driver only support a subset of Cadence DSI bridge capabilities. > > This driver has been tested/debugged in a simulated environment which > explains why some of the features are missing. Here is a > non-exhaustive list of missing features: > * burst mode > * DPHY init/configuration steps > * support for additional input interfaces (SDI input) > > DSI commands and non-burst video mode have been tested. > > Signed-off-by: Boris Brezillon > Reviewed-by: Andrzej Hajda > Acked-by: Eric Anholt > Reviewed-by: Archit Taneja Applied both patches to drm-misc-next. > --- > Changes in v8: > - Update my email address > > Changes in v7: > - Use DIV_ROUND_UP_ULL() to fix a build error on arm 32-bit > - Add Archit's R-b > > Changes in v6: > - Use SPDX header > - Do not enable the sys_clk in the probe function > - Remove unneeded udelay() > - Add a function to make sure the PLL and pixel clock are close enough > to be recoverable if they don't match exactly > - Add the DPHY init sequence used in simulation (likely to be different > based on each SoC integration) > > Changes in v5: > - Add runtime PM support > > Changes in v4: > - Fix typos > - Rename clks as suggested by Tomi > - Fix DSI setup done in cdns_dsi_bridge_enable() > - Add a precision about where this bridge is supposed to used to the > Kconfig entry > - Let DRM_CDNS_DSI select DRM_PANEL_BRIDGE > - Remove the IP version from the DT compatible name > - Adapt register the layout to match the one used in the last revision > of the IP (hopefully the final version) > > Changes in v3: > - replace magic values by real timing calculation. The DPHY PLL clock > is still hardcoded since we don't have a working DPHY block yet, and > this is the piece of HW we need to dynamically configure the PLL > rate based on the display refresh rate and the resolution. > - parse DSI devices represented with the OF-graph. This is needed to > support DSI devices controlled through an external bus like I2C or > SPI. > - use the DRM panel-bridge infrastructure to simplify the DRM panel > logic > > Changes in v2: > - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes > - return the correct error when devm_clk_get(sysclk) fails > - add missing depends on OF and select DRM_PANEL in the Kconfig entry > > DSI runtime PM > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/cdns-dsi.c | 1623 > + > 3 files changed, 1634 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 42c9c2d13752..1d75d3a1f951 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -25,6 +25,16 @@ config DRM_ANALOGIX_ANX78XX > the HDMI output of an application processor to MyDP > or DisplayPort. > > +config DRM_CDNS_DSI > + tristate "Cadence DPI/DSI bridge" > + select DRM_KMS_HELPER > + select DRM_MIPI_DSI > + select DRM_PANEL_BRIDGE > + depends on OF > + help > + Support Cadence DPI to DSI bridge. This is an internal > + bridge and is meant to be directly embedded in a SoC. > + > config DRM_DUMB_VGA_DAC > tristate "Dumb VGA DAC Bridge support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index fd90b16a65c0..35f88d48ec20 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > +obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += > megachips-stdp-ge-b850v3-fw.o > diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c > b/drivers/gpu/drm/bridge/cdns-dsi.c > new file mode 100644 > index ..c255fc3e1be5 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/cdns-dsi.c > @@ -0,0 +1,1623 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright: 2017 Cadence Design Systems, Inc. > + * > + * Author: Boris Brezillon > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define IP_CONF 0x0 > +#define SP_HS_FIFO_DEPTH(x) (((x) & GENMASK(30, 26)) >> 26) > +#define SP_LP_FIFO_DEPTH(x) (((x) & GENMASK(25, 21)) >> 21) > +#define VRS_FIFO_DEPTH(x)(((x) & GENMASK(20, 16)) >> 16) > +#define DIRCMD_FIFO_DEPTH(x) (((x) & GENMASK(15, 13)) >> 13) > +#define SDI_IFACE_32 BIT(12) > +#d
[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal
https://bugs.freedesktop.org/show_bug.cgi?id=106191 --- Comment #9 from François Jacques --- Created attachment 139017 --> https://bugs.freedesktop.org/attachment.cgi?id=139017&action=edit dmesg with 4.16.3 backtrace disappears in 4.16.3, still no image. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal
https://bugs.freedesktop.org/show_bug.cgi?id=106191 --- Comment #8 from François Jacques --- Thank you so much Alex to help out on this! I'll generate another dmesg dump with 4.16.3 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal
https://bugs.freedesktop.org/show_bug.cgi?id=106191 --- Comment #7 from François Jacques --- Created attachment 139014 --> https://bugs.freedesktop.org/attachment.cgi?id=139014&action=edit dmesg with 4.16.2 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106188] Can't successfully set pstates in pp_od_clk_voltage
https://bugs.freedesktop.org/show_bug.cgi?id=106188 --- Comment #3 from tempel.jul...@gmail.com --- I figured out that the cause of the described behavior is that it doesn't allow me to really increase the GPU clock. So I can set "echo "s 7 1194 900" > /sys/class/drm/card0/device/pp_od_clk_voltage" and it works correctly. But when I set e.g. "echo "s 7 1199 900" > /sys/class/drm/card0/device/pp_od_clk_voltage", the clock doesn't get over pstate 6. Is this restriction by purpose? It's not there with Wattman on Windows. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tinydrm/mi0283qt: Always set rotation value
The PiTFT (ili9340) has a hardware reset circuit that resets only on power-on and not on each reboot through a gpio like the rpi-display does. As a result, we need to always apply the rotation value regardless of the display "on/off" state. Moved the rotation setting code below out_enable:. Signed-off-by: Tom Callaway --- drivers/gpu/drm/tinydrm/mi0283qt.c | 41 +- 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c b/drivers/gpu/drm/tinydrm/mi0283qt.c index 4e6d2ee94e55..2bb9e3ce4823 100644 --- a/drivers/gpu/drm/tinydrm/mi0283qt.c +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c @@ -84,24 +84,6 @@ static void mi0283qt_enable(struct drm_simple_display_pipe *pipe, /* Memory Access Control */ mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT, MIPI_DCS_PIXEL_FMT_16BIT); - switch (mipi->rotation) { - default: - addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY | - ILI9341_MADCTL_MX; - break; - case 90: - addr_mode = ILI9341_MADCTL_MY; - break; - case 180: - addr_mode = ILI9341_MADCTL_MV; - break; - case 270: - addr_mode = ILI9341_MADCTL_MX; - break; - } - addr_mode |= ILI9341_MADCTL_BGR; - mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode); - /* Frame Rate */ mipi_dbi_command(mipi, ILI9341_FRMCTR1, 0x00, 0x1b); @@ -127,6 +109,29 @@ static void mi0283qt_enable(struct drm_simple_display_pipe *pipe, msleep(100); out_enable: + /* The PiTFT (ili9340) has a hardware reset circuit that +* resets only on power-on and not on each reboot through +* a gpio like the rpi-display does. +* As a result, we need to always apply the rotation value +* regardless of the display "on/off" state. +*/ + switch (mipi->rotation) { + default: + addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY | + ILI9341_MADCTL_MX; + break; + case 90: + addr_mode = ILI9341_MADCTL_MY; + break; + case 180: + addr_mode = ILI9341_MADCTL_MV; + break; + case 270: + addr_mode = ILI9341_MADCTL_MX; + break; + } + addr_mode |= ILI9341_MADCTL_BGR; + mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode); mipi_dbi_enable_flush(mipi, crtc_state, plane_state); } -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 10/10] MAINTAINERS: update Mediatek Soc entry
From: Matthias Brugger Mediatek SoCs include several soc specific drivers as well as a mfd device. Add these to the maintainers file. Signed-off-by: Matthias Brugger --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0a1410d5a621..74f7ea345096 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1621,6 +1621,8 @@ F:arch/arm/boot/dts/mt7* F: arch/arm/boot/dts/mt8* F: arch/arm/mach-mediatek/ F: arch/arm64/boot/dts/mediatek/ +F: drivers/soc/mediatek/ +F: drivers/mfd/mtk-mmsys.c N: mtk K: mediatek -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 08/10] clk: mediatek: mt8173-mm: switch to mfd device
From: Matthias Brugger As the new mfd device is in place, switch probing for the MMSYS to support invocation from the mfd device. Signed-off-by: Matthias Brugger Acked-by: Stephen Boyd --- drivers/clk/mediatek/clk-mt8173.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/clk/mediatek/clk-mt8173.c b/drivers/clk/mediatek/clk-mt8173.c index 96c292c3e440..abd2592078d4 100644 --- a/drivers/clk/mediatek/clk-mt8173.c +++ b/drivers/clk/mediatek/clk-mt8173.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "clk-mtk.h" #include "clk-gate.h" @@ -1152,10 +1153,13 @@ static void __init mtk_imgsys_init(struct device_node *node) } CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt8173-imgsys", mtk_imgsys_init); -static void __init mtk_mmsys_init(struct device_node *node) +static int mtk_mmsys_probe(struct platform_device *pdev) { struct clk_onecell_data *clk_data; int r; + struct device_node *node; + + node = pdev->dev.parent->of_node; clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK); @@ -1166,8 +1170,17 @@ static void __init mtk_mmsys_init(struct device_node *node) if (r) pr_err("%s(): could not register clock provider: %d\n", __func__, r); + + return r; } -CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt8173-mmsys", mtk_mmsys_init); + +static struct platform_driver clk_mt8173_mm_drv = { + .probe = mtk_mmsys_probe, + .driver = { + .name = "clk-mt8173-mm", + }, +}; +builtin_platform_driver(clk_mt8173_mm_drv); static void __init mtk_vdecsys_init(struct device_node *node) { -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 09/10] drm: mediatek: Omit warning on probe defers
From: Matthias Brugger When probe through the MFD, it can happen that the clock drivers wasn't probed before the ddp driver gets invoked. The driver used to omit a warning that the driver failed to get the clocks. Omit this error on the defered probe path. Signed-off-by: Matthias Brugger --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index bafc5c77c4fb..6b399348a2dc 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c @@ -374,7 +374,8 @@ static int mtk_ddp_probe(struct platform_device *pdev) ddp->clk = devm_clk_get(dev, NULL); if (IS_ERR(ddp->clk)) { - dev_err(dev, "Failed to get clock\n"); + if (PTR_ERR(ddp->clk) != -EPROBE_DEFER) + dev_err(dev, "Failed to get clock\n"); return PTR_ERR(ddp->clk); } -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 07/10] drm/mediatek: Add mfd support for mt8173
From: Matthias Brugger Use the MFD device for SoC mt8173. Probing via devicetree is no longer needed for any SoC, so delete it. Signed-off-by: Matthias Brugger Reviewed-by: Philipp Zabel --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 +++- 1 file changed, 7 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 88ee35907744..3cc433ebfa8f 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -399,20 +399,12 @@ static int mtk_drm_probe(struct platform_device *pdev) INIT_WORK(&private->commit.work, mtk_atomic_work); private->data = of_device_get_match_data(dev); - /* Check if called from mfd */ - if (!dev->of_node) { - mmsys_node = pdev->dev.parent->of_node; - private->data = (struct mtk_mmsys_driver_data *) - platform_get_device_id(pdev)->driver_data; - private->config_regs = - syscon_node_to_regmap(mmsys_node); - parent_node = mmsys_node->parent; - } else { - private->config_regs = syscon_node_to_regmap(dev->of_node); - if (IS_ERR(private->config_regs)) - return PTR_ERR(private->config_regs); - parent_node = dev->of_node->parent; - } + mmsys_node = pdev->dev.parent->of_node; + private->data = (struct mtk_mmsys_driver_data *) + platform_get_device_id(pdev)->driver_data; + private->config_regs = + syscon_node_to_regmap(mmsys_node); + parent_node = mmsys_node->parent; /* Iterate over sibling DISP function blocks */ for_each_child_of_node(parent_node, node) { @@ -555,14 +547,9 @@ static int mtk_drm_sys_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend, mtk_drm_sys_resume); -static const struct of_device_id mtk_drm_of_ids[] = { - { .compatible = "mediatek,mt8173-mmsys", - .data = &mt8173_mmsys_driver_data}, - { } -}; - static const struct platform_device_id mtk_drm_ids[] = { { "drm-mt2701-mm", (kernel_ulong_t)&mt2701_mmsys_driver_data }, + { "drm-mt8173-mm", (kernel_ulong_t)&mt8173_mmsys_driver_data }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(platform, mtk_drm_ids); @@ -572,7 +559,6 @@ static struct platform_driver mtk_drm_platform_driver = { .remove = mtk_drm_remove, .driver = { .name = "mediatek-drm", - .of_match_table = mtk_drm_of_ids, .pm = &mtk_drm_pm_ops, }, .id_table = mtk_drm_ids, -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 06/10] mfd: mtk-mmsys: Add mt8173 nodes
From: Matthias Brugger Add devices for the mt8173 SoC. Signed-off-by: Matthias Brugger Reviewed-by: Philipp Zabel --- drivers/mfd/mtk-mmsys.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c index c802343fb1c6..5585a561a02f 100644 --- a/drivers/mfd/mtk-mmsys.c +++ b/drivers/mfd/mtk-mmsys.c @@ -19,6 +19,7 @@ enum { MMSYS_MT2701 = 1, + MMSYS_MT8173, }; static const struct mfd_cell mmsys_mt2701_devs[] = { @@ -26,6 +27,12 @@ static const struct mfd_cell mmsys_mt2701_devs[] = { { .name = "drm-mt2701-mm", }, }; +static const struct mfd_cell mmsys_mt8173_devs[] = { + { .name = "clk-mt8173-mm", }, + { .name = "drm-mt8173-mm", }, +}; + + static int mmsys_probe(struct platform_device *pdev) { const struct mfd_cell *mmsys_cells; @@ -44,6 +51,10 @@ static int mmsys_probe(struct platform_device *pdev) mmsys_cells = mmsys_mt2701_devs; nr_cells = ARRAY_SIZE(mmsys_mt2701_devs); break; + case MMSYS_MT8173: + mmsys_cells = mmsys_mt8173_devs; + nr_cells = ARRAY_SIZE(mmsys_mt8173_devs); + break; default: return -ENODEV; } @@ -62,6 +73,9 @@ static const struct of_device_id of_match_mmsys[] = { { .compatible = "mediatek,mt2701-mmsys", .data = (void *) MMSYS_MT2701, }, + { .compatible = "mediatek,mt8173-mmsys", + .data = (void *) MMSYS_MT8173, + }, { /* sentinel */ }, }; -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 05/10] clk: mediatek: mt2701-mm: switch to mfd device
From: Matthias Brugger As the new mfd device is in place, switch probing for the MMSYS to support invocation from the mfd device. Signed-off-by: Matthias Brugger Acked-by: Stephen Boyd --- drivers/clk/mediatek/clk-mt2701-mm.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/clk/mediatek/clk-mt2701-mm.c b/drivers/clk/mediatek/clk-mt2701-mm.c index fe1f85072fc5..4517525887dd 100644 --- a/drivers/clk/mediatek/clk-mt2701-mm.c +++ b/drivers/clk/mediatek/clk-mt2701-mm.c @@ -87,16 +87,13 @@ static const struct mtk_gate mm_clks[] = { GATE_DISP1(CLK_MM_TVE_FMM, "mm_tve_fmm", "mm_sel", 14), }; -static const struct of_device_id of_match_clk_mt2701_mm[] = { - { .compatible = "mediatek,mt2701-mmsys", }, - {} -}; - static int clk_mt2701_mm_probe(struct platform_device *pdev) { struct clk_onecell_data *clk_data; int r; - struct device_node *node = pdev->dev.of_node; + struct device_node *node; + + node = pdev->dev.parent->of_node; clk_data = mtk_alloc_clk_data(CLK_MM_NR); @@ -116,7 +113,6 @@ static struct platform_driver clk_mt2701_mm_drv = { .probe = clk_mt2701_mm_probe, .driver = { .name = "clk-mt2701-mm", - .of_match_table = of_match_clk_mt2701_mm, }, }; -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 01/10] dt-bindings: mediatek: mmsys: Add support for mfd
From: Matthias Brugger Add binding description for the mmsys mfd for some Mediatek devices. mmsys has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display subsystem. Signed-off-by: Matthias Brugger --- .../bindings/arm/mediatek/mediatek,mmsys.txt | 2 -- .../bindings/display/mediatek/mediatek,disp.txt| 2 +- .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 ++ 3 files changed, 28 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt index 4eb8bbe15c01..4468345f8b1a 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt @@ -6,10 +6,8 @@ The Mediatek mmsys controller provides various clocks to the system. Required Properties: - compatible: Should be one of: - - "mediatek,mt2701-mmsys", "syscon" - "mediatek,mt2712-mmsys", "syscon" - "mediatek,mt6797-mmsys", "syscon" - - "mediatek,mt8173-mmsys", "syscon" - #clock-cells: Must be 1 The mmsys controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 383183a89164..85a3b4ec06cd 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -9,7 +9,7 @@ function block. All DISP device tree nodes must be siblings to the central MMSYS_CONFIG node. For a description of the MMSYS_CONFIG binding, see -Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt. +Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt DISP function blocks diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt b/Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt new file mode 100644 index ..2331ae16917e --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt @@ -0,0 +1,27 @@ +MediaTek MMSYS Multifunction Device Driver + +MMSYS is a multifunction device with the following sub modules: +- clocks for the multi-media subsystem +- central node for the DRM subsystem. + +This document describes the binding for MFD device. The MFD takes care to initailize +the clock driver and the DRM driver. More info see +Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt + +Required properties: +- compatible: Should be one of: + - "mediatek,mt2701-mmsys", "syscon" + - "mediatek,mt8173-mmsys", "syscon" +- #clock-cells: Must be 1 + +Optional properties: +- power-domains: list of powerdomains needed for the subsystem to work + +Example: + +mmsys: clock-controller@1400 { + compatible = "mediatek,mt8173-mmsys", "syscon"; + reg = <0 0x1400 0 0x1000>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + #clock-cells = <1>; +}; -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 02/10] drm/mediatek: Use regmap for register access
From: Matthias Brugger The mmsys memory space is shared between the drm and the clk driver. Use regmap to access it. Signed-off-by: Matthias Brugger Reviewed-by: Philipp Zabel --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++-- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 38 + drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 ++-- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 --- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- 5 files changed, 24 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c index 658b8dd45b83..4c65873b4867 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c @@ -33,7 +33,7 @@ * @enabled: records whether crtc_enable succeeded * @planes: array of 4 drm_plane structures, one for each overlay plane * @pending_planes: whether any plane has pending changes to be applied - * @config_regs: memory mapped mmsys configuration register space + * @config_regs: regmap mapped mmsys configuration register space * @mutex: handle to one of the ten disp_mutex streams * @ddp_comp_nr: number of components in ddp_comp * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc @@ -48,7 +48,7 @@ struct mtk_drm_crtc { struct drm_planeplanes[OVL_LAYER_NR]; boolpending_planes; - void __iomem*config_regs; + struct regmap *config_regs; struct mtk_disp_mutex *mutex; unsigned intddp_comp_nr; struct mtk_ddp_comp **ddp_comp; diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index 8130f3dab661..bafc5c77c4fb 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c @@ -185,53 +185,45 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur, return value; } -static void mtk_ddp_sout_sel(void __iomem *config_regs, +static void mtk_ddp_sout_sel(struct regmap *config_regs, enum mtk_ddp_comp_id cur, enum mtk_ddp_comp_id next) { if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) - writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1, - config_regs + DISP_REG_CONFIG_OUT_SEL); + regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL, + BLS_TO_DSI_RDMA1_TO_DPI1); } -void mtk_ddp_add_comp_to_path(void __iomem *config_regs, +void mtk_ddp_add_comp_to_path(struct regmap *config_regs, enum mtk_ddp_comp_id cur, enum mtk_ddp_comp_id next) { - unsigned int addr, value, reg; + unsigned int addr, value; value = mtk_ddp_mout_en(cur, next, &addr); - if (value) { - reg = readl_relaxed(config_regs + addr) | value; - writel_relaxed(reg, config_regs + addr); - } + if (value) + regmap_update_bits(config_regs, addr, value, value); mtk_ddp_sout_sel(config_regs, cur, next); value = mtk_ddp_sel_in(cur, next, &addr); - if (value) { - reg = readl_relaxed(config_regs + addr) | value; - writel_relaxed(reg, config_regs + addr); - } + if (value) + regmap_update_bits(config_regs, addr, value, value); } -void mtk_ddp_remove_comp_from_path(void __iomem *config_regs, +void mtk_ddp_remove_comp_from_path(struct regmap *config_regs, enum mtk_ddp_comp_id cur, enum mtk_ddp_comp_id next) { - unsigned int addr, value, reg; + unsigned int addr, value; value = mtk_ddp_mout_en(cur, next, &addr); - if (value) { - reg = readl_relaxed(config_regs + addr) & ~value; - writel_relaxed(reg, config_regs + addr); - } + if (value) + regmap_update_bits(config_regs, addr, value, 0); value = mtk_ddp_sel_in(cur, next, &addr); - if (value) { - reg = readl_relaxed(config_regs + addr) & ~value; - writel_relaxed(reg, config_regs + addr); - } + if (value) + regmap_update_bits(config_regs, addr, value, 0); } struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int id) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h index f9a799168077..32e12f33b76a 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h @@ -20,10 +20,10 @@ struct regmap; struct device; struct mtk_disp_mutex; -void mtk_ddp_add_comp_to_path(void __iomem *config_regs, +void mtk_ddp_add_comp_to_path(struct regmap *config_regs, enum m
[v2 03/10] mfd: mtk-mmsys: Add mmsys driver
From: Matthias Brugger The MMSYS subsystem includes clocks and drm components. This patch adds a MFD device to probe both drivers from the same device tree compatible. Signed-off-by: Matthias Brugger --- drivers/mfd/Kconfig | 9 ++ drivers/mfd/Makefile| 2 ++ drivers/mfd/mtk-mmsys.c | 79 + 3 files changed, 90 insertions(+) create mode 100644 drivers/mfd/mtk-mmsys.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index b860eb5aa194..a2c928e26026 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -378,6 +378,15 @@ config MFD_MC13XXX_I2C help Select this if your MC13xxx is connected via an I2C bus. +config MFD_MEDIATEK_MMSYS + tristate "Mediatek MMSYS interface" + select MDF_CORE + select REGMAP_MMIO + help + Select this if you have a MMSYS subsystem in your SoC. The + MMSYS subsystem has at least a clock driver part and some + DRM components. + config MFD_MXS_LRADC tristate "Freescale i.MX23/i.MX28 LRADC" depends on ARCH_MXS || COMPILE_TEST diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index d9d2cf0d32ef..b96118bd68d9 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -98,6 +98,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o obj-$(CONFIG_MFD_MC13XXX_SPI) += mc13xxx-spi.o obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o +obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o + obj-$(CONFIG_MFD_CORE) += mfd-core.o obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c new file mode 100644 index ..c802343fb1c6 --- /dev/null +++ b/drivers/mfd/mtk-mmsys.c @@ -0,0 +1,79 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/* + * mtk-mmsys.c -- Mediatek MMSYS multi-function driver + * + * Copyright (c) 2018 Matthias Brugger + * + * Author: Matthias Brugger + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +enum { + MMSYS_MT2701 = 1, +}; + +static const struct mfd_cell mmsys_mt2701_devs[] = { + { .name = "clk-mt2701-mm", }, + { .name = "drm-mt2701-mm", }, +}; + +static int mmsys_probe(struct platform_device *pdev) +{ + const struct mfd_cell *mmsys_cells; + int nr_cells; + long id; + int ret; + + id = (long) of_device_get_match_data(&pdev->dev); + if (!id) { + dev_err(&pdev->dev, "of_device_get match_data() failed\n"); + return -EINVAL; + } + + switch (id) { + case MMSYS_MT2701: + mmsys_cells = mmsys_mt2701_devs; + nr_cells = ARRAY_SIZE(mmsys_mt2701_devs); + break; + default: + return -ENODEV; + } + + ret = devm_mfd_add_devices(&pdev->dev, 0, mmsys_cells, nr_cells, + NULL, 0, NULL); + if (ret) { + dev_err(&pdev->dev, "failed to add MFD devices %d\n", ret); + return ret; + } + + return 0; +}; + +static const struct of_device_id of_match_mmsys[] = { + { .compatible = "mediatek,mt2701-mmsys", + .data = (void *) MMSYS_MT2701, + }, + { /* sentinel */ }, +}; + +static struct platform_driver mmsys_drv = { + .probe = mmsys_probe, + .driver = { + .name = "mediatek-mmysys", + .of_match_table = of_match_ptr(of_match_mmsys), + }, +}; + +builtin_platform_driver(mmsys_drv); + +MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver"); +MODULE_LICENSE("GPL"); -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 04/10] drm/mediatek: mt2701: switch to mfd probing.
From: Matthias Brugger With the mtk-mmsys MFD device in place, we switch the probing for mt2701 from device-tree to mfd. Signed-off-by: Matthias Brugger --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 +++--- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index a48e28adad09..88ee35907744 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -386,7 +386,7 @@ static int mtk_drm_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct mtk_drm_private *private; - struct device_node *node; + struct device_node *node, *parent_node, *mmsys_node; struct component_match *match = NULL; int ret; int i; @@ -399,12 +399,23 @@ static int mtk_drm_probe(struct platform_device *pdev) INIT_WORK(&private->commit.work, mtk_atomic_work); private->data = of_device_get_match_data(dev); - private->config_regs = syscon_node_to_regmap(dev->of_node); - if (IS_ERR(private->config_regs)) - return PTR_ERR(private->config_regs); + /* Check if called from mfd */ + if (!dev->of_node) { + mmsys_node = pdev->dev.parent->of_node; + private->data = (struct mtk_mmsys_driver_data *) + platform_get_device_id(pdev)->driver_data; + private->config_regs = + syscon_node_to_regmap(mmsys_node); + parent_node = mmsys_node->parent; + } else { + private->config_regs = syscon_node_to_regmap(dev->of_node); + if (IS_ERR(private->config_regs)) + return PTR_ERR(private->config_regs); + parent_node = dev->of_node->parent; + } /* Iterate over sibling DISP function blocks */ - for_each_child_of_node(dev->of_node->parent, node) { + for_each_child_of_node(parent_node, node) { const struct of_device_id *of_id; enum mtk_ddp_comp_type comp_type; int comp_id; @@ -545,13 +556,17 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend, mtk_drm_sys_resume); static const struct of_device_id mtk_drm_of_ids[] = { - { .compatible = "mediatek,mt2701-mmsys", - .data = &mt2701_mmsys_driver_data}, { .compatible = "mediatek,mt8173-mmsys", .data = &mt8173_mmsys_driver_data}, { } }; +static const struct platform_device_id mtk_drm_ids[] = { + { "drm-mt2701-mm", (kernel_ulong_t)&mt2701_mmsys_driver_data }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(platform, mtk_drm_ids); + static struct platform_driver mtk_drm_platform_driver = { .probe = mtk_drm_probe, .remove = mtk_drm_remove, @@ -560,6 +575,7 @@ static struct platform_driver mtk_drm_platform_driver = { .of_match_table = mtk_drm_of_ids, .pm = &mtk_drm_pm_ops, }, + .id_table = mtk_drm_ids, }; static struct platform_driver * const mtk_drm_drivers[] = { -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 00/10] arm/arm64: mediatek: Fix mmsys device probing
From: Matthias Brugger Changes since v1: - add binding documentation - ddp: use regmap_update_bits - ddp: ignore EPROBE_DEFER on clock probing - mfd: delete mmsys_private - add Reviewed-by and Acked-by tags --- MMSYS in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display subsystem. Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver get probed, which in effect breaks graphics on mt8173 and mt2701. This patch set introduces a new mfd device, which binds against the mmsys compatible and takes care of probing the needed devices. It was tested on the bananapi-r2 and the Acer R13 Chromebook. Matthias Brugger (10): dt-bindings: mediatek: mmsys: Add support for mfd drm/mediatek: Use regmap for register access mfd: mtk-mmsys: Add mmsys driver drm/mediatek: mt2701: switch to mfd probing. clk: mediatek: mt2701-mm: switch to mfd device mfd: mtk-mmsys: Add mt8173 nodes drm/mediatek: Add mfd support for mt8173 clk: mediatek: mt8173-mm: switch to mfd device drm: mediatek: Omit warning on probe defers MAINTAINERS: update Mediatek Soc entry .../bindings/arm/mediatek/mediatek,mmsys.txt | 2 - .../bindings/display/mediatek/mediatek,disp.txt| 2 +- .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 +++ MAINTAINERS| 2 + drivers/clk/mediatek/clk-mt2701-mm.c | 10 +-- drivers/clk/mediatek/clk-mt8173.c | 17 +++- drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 4 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 -- drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 33 drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- drivers/mfd/Kconfig| 9 +++ drivers/mfd/Makefile | 2 + drivers/mfd/mtk-mmsys.c| 93 ++ 14 files changed, 189 insertions(+), 59 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt create mode 100644 drivers/mfd/mtk-mmsys.c -- 2.16.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106188] Can't successfully set pstates in pp_od_clk_voltage
https://bugs.freedesktop.org/show_bug.cgi?id=106188 --- Comment #2 from tempel.jul...@gmail.com --- Thanks for your response. I somehow forgot the missing ">", whoops. I now almost got it working like desired, thanks! However, there is a small problem left: It doesn't switch into pstate 7. I set up: echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "s 0 214 721" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 1 389 721" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 2 844 725" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 3 1009 818" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 4 1079 875" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 5 1134 880" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 6 1179 890" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage But according to /sys/kernel/debug/dri/0/amdgpu_pm_info, pstate 6 (1179 890) is the maximum of chosen clocks. I set up Unigine Valley to run in 720p with 8xMSAA, so there is no high power consumption which could make the GPU throttle down to a lower state, so it definitely should switch to pstate 7. I also tried making s 7 and s 6 the same, but then it's just limited to an even lower pstate. So I fail to get to my desired 1209MHz 900mV. It also seems like setting up power_dpm_force_performance_level to manual isn't actually required, at least it doesn't make any difference here (or I'm missing something). Btw: Since I'm already bugging you with this :) : Is there a way to also increase the maximum allowed power consumption? There are /sys/class/drm/card0/device/hwmon/hwmon0/power1_cap and /sys/class/drm/card0/device/hwmon/hwmon0/power1_cap_max containing the maximum ASIC power (at least it looks to me that way), but I haven't been able to successfully alter those to e.g. raise the limit of my Baffin GPU to 60 Watts. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] drm/arm/malidp: Enable/disable the scaling engine interrupts with memory writeback
On Mon, Apr 23, 2018 at 03:50:49PM +0100, Ayan Kumar Halder wrote: > Scaling engine interrupts need to be enabled/disabled as and when memwrite > is enabled and disabled. The reason being scaling engine interrupts are > used only by the memory writeout layer. > > This patch depends on: > https://lkml.org/lkml/2017/5/15/695 > > Signed-off-by: Ayan Kumar Halder > > --- > Changes in v2:- > - Removed the change id and modified the commit message > --- > drivers/gpu/drm/arm/malidp_hw.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c > index f5633bc..90d76e4 100644 > --- a/drivers/gpu/drm/arm/malidp_hw.c > +++ b/drivers/gpu/drm/arm/malidp_hw.c > @@ -621,12 +621,14 @@ static int malidp550_enable_memwrite(struct > malidp_hw_device *hwdev, > malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | > MALIDP_SE_MEMWRITE_EN, > MALIDP550_SE_CONTROL); > > + malidp_se_irq_hw_init(hwdev); > return 0; > } > > static void malidp550_disable_memwrite(struct malidp_hw_device *hwdev) > { > u32 base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK); > + malidp_se_irq_fini(hwdev); > malidp_hw_clearbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | > MALIDP_SE_MEMWRITE_EN, > MALIDP550_SE_CONTROL); > malidp_hw_clearbits(hwdev, MALIDP_SCALE_ENGINE_EN, base + > MALIDP_DE_DISPLAY_FUNC); We now know that this patch is broken, because it disables interrupts for the writeback after a previous commit has enabled them but before the writeback engine has finished writing, so the better place for enabling and disabling the SE IRQs is in the malidp_pm_{suspend,resume} functions, not here. Only for this patch: NACK. Best regards, Liviu > -- > 2.7.4 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106188] Can't successfully set pstates in pp_od_clk_voltage
https://bugs.freedesktop.org/show_bug.cgi?id=106188 --- Comment #1 from Alex Deucher --- (In reply to tempel.julian from comment #0) > Hello, > I specified "amdgpu.ppfeaturemask=0x" as a boot parameter so I could > access "/sys/class/drm/card0/device/pp_od_clk_voltage". > The pstate table for source and memory clocks looks correct. > > When I run "echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage", it returns "s 7 1209 900 > /sys/class/drm/card0/device/pp_od_clk_voltage". > When I run "echo "c" /sys/class/drm/card0/device/pp_od_clk_voltage" > afterwards, it returns "c /sys/class/drm/card0/device/pp_od_clk_voltage". > Are you redirecting to the file? Something like the following should work: echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage > However, the change is not applied. When I do "cat > /sys/class/drm/card0/device/pp_od_clk_voltage", it still says "7: > 1196Mhz 1006 mV". > And when I run "watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info", > it reports > " 1196 MHz (SCLK) > 981 mV (VDDGFX) > ". > > Am I making a mistake somewhere or should it work like this? > > I also tried "echo "manual" > > /sys/class/drm/card0/device/power_dpm_force_performance_level" and setting > pstates 5-7, but that didn't help either. You have to set manual mode before you can manually edit the state. You also have to be root (or have permission) to write to these files. > In the documentation, I read that pp_od_clk_voltage should also include > OD_range, but it's not there for me. The patch is on the mailing list, but hasn't been committed yet. https://patchwork.freedesktop.org/patch/217812/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 8/8] drm/arm/malidp: Added the late system pm functions
malidp_pm_suspend_late checks if the runtime status is not suspended and if so, invokes malidp_runtime_pm_suspend which disables the display engine/core interrupts and the clocks. It sets the runtime status as suspended. The difference between suspend() and suspend_late() is as follows:- 1. suspend() makes the device quiescent. In our case, we invoke the DRM helper which disables the CRTC. This would have invoked runtime pm suspend but the system suspend process disables runtime pm. 2. suspend_late() It continues the suspend operations of the drm device which was started by suspend(). In our case, it performs the same functionality as runtime_suspend(). The complimentary functions are resume() and resume_early(). In the case of resume_early(), we invoke malidp_runtime_pm_resume() which enables the clocks and the interrupts. It sets the runtime status as active. If the device was in runtime suspend mode before system suspend was called, pm_runtime_work() will put the device back in runtime suspended mode( after the complete system has been resumed). Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id and modified the commit message --- drivers/gpu/drm/arm/malidp_drv.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index bd44a6d..f6124d8 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct device *dev) return 0; } +static int __maybe_unused malidp_pm_suspend_late(struct device *dev) +{ + if (!pm_runtime_status_suspended(dev)) { + malidp_runtime_pm_suspend(dev); + pm_runtime_set_suspended(dev); + } + return 0; +} + +static int __maybe_unused malidp_pm_resume_early(struct device *dev) +{ + malidp_runtime_pm_resume(dev); + pm_runtime_set_active(dev); + return 0; +} + static const struct dev_pm_ops malidp_pm_ops = { SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \ + SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, malidp_pm_resume_early) \ SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, malidp_runtime_pm_resume, NULL) }; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] drm/arm/malidp: Enable/disable the scaling engine interrupts with memory writeback
Scaling engine interrupts need to be enabled/disabled as and when memwrite is enabled and disabled. The reason being scaling engine interrupts are used only by the memory writeout layer. This patch depends on: https://lkml.org/lkml/2017/5/15/695 Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id and modified the commit message --- drivers/gpu/drm/arm/malidp_hw.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index f5633bc..90d76e4 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -621,12 +621,14 @@ static int malidp550_enable_memwrite(struct malidp_hw_device *hwdev, malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | MALIDP_SE_MEMWRITE_EN, MALIDP550_SE_CONTROL); + malidp_se_irq_hw_init(hwdev); return 0; } static void malidp550_disable_memwrite(struct malidp_hw_device *hwdev) { u32 base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK); + malidp_se_irq_fini(hwdev); malidp_hw_clearbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | MALIDP_SE_MEMWRITE_EN, MALIDP550_SE_CONTROL); malidp_hw_clearbits(hwdev, MALIDP_SCALE_ENGINE_EN, base + MALIDP_DE_DISPLAY_FUNC); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] drm/arm/malidp: Split malidp_se_irq_init
Extract the hardware initialisation part from malidp_se_irq_init() into the malidp_se_irq_hw_init() which will be later invoked from malidpxxx_enable_memwrite() when it needs to re-enable the interrupts. Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id --- drivers/gpu/drm/arm/malidp_hw.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index 3e73370..f5633bc 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -163,6 +163,7 @@ static const u16 dp500_se_scaling_coeffs[][SE_N_SCALING_COEFFS] = { }; #define MALIDP_DE_DEFAULT_PREFETCH_START 5 +static void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev); static int malidp500_query_hw(struct malidp_hw_device *hwdev) { @@ -952,6 +953,16 @@ static irqreturn_t malidp_se_irq(int irq, void *arg) return IRQ_HANDLED; } +static void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev) +{ + /* ensure interrupts are disabled */ + malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK, 0x); + malidp_hw_clear_irq(hwdev, MALIDP_SE_BLOCK, 0x); + + malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK, +hwdev->hw->map.se_irq_map.irq_mask); +} + static irqreturn_t malidp_se_irq_thread_handler(int irq, void *arg) { return IRQ_HANDLED; @@ -975,8 +986,7 @@ int malidp_se_irq_init(struct drm_device *drm, int irq) return ret; } - malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK, -hwdev->hw->map.se_irq_map.irq_mask); + malidp_se_irq_hw_init(hwdev); return 0; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/8] drm/arm/malidp: Modified the prototype of malidp_se_irq_fini
'struct drm_device' is being replaced with 'struct malidp_hw_device' as the function argument.The reason being the dependency of malidp_se_irq_fini on 'struct drm_device' needs to be removed so as to enable it to call from functions which receives 'struct malidp_hw_device' as argument. Furthermore, there is no way to retrieve 'struct drm_device' from 'struct malidp_hw_device' Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id --- drivers/gpu/drm/arm/malidp_drv.c | 4 ++-- drivers/gpu/drm/arm/malidp_hw.c | 5 + drivers/gpu/drm/arm/malidp_hw.h | 2 +- 3 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index ed38ba9..f7a8beb 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -653,7 +653,7 @@ static int malidp_bind(struct device *dev) fbdev_fail: pm_runtime_get_sync(dev); vblank_fail: - malidp_se_irq_fini(drm); + malidp_se_irq_fini(hwdev); malidp_de_irq_fini(hwdev); drm->irq_enabled = false; irq_init_fail: @@ -690,7 +690,7 @@ static void malidp_unbind(struct device *dev) drm_kms_helper_poll_fini(drm); pm_runtime_get_sync(dev); drm_crtc_vblank_off(&malidp->crtc); - malidp_se_irq_fini(drm); + malidp_se_irq_fini(hwdev); malidp_de_irq_fini(hwdev); drm->irq_enabled = false; component_unbind_all(dev, drm); diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index b13dfac..8fb02f3 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -970,11 +970,8 @@ int malidp_se_irq_init(struct drm_device *drm, int irq) return 0; } -void malidp_se_irq_fini(struct drm_device *drm) +void malidp_se_irq_fini(struct malidp_hw_device *hwdev) { - struct malidp_drm *malidp = drm->dev_private; - struct malidp_hw_device *hwdev = malidp->dev; - malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK, hwdev->hw->map.se_irq_map.irq_mask); } diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h index 6e2a2f6..6607aba 100644 --- a/drivers/gpu/drm/arm/malidp_hw.h +++ b/drivers/gpu/drm/arm/malidp_hw.h @@ -299,7 +299,7 @@ static inline void malidp_hw_enable_irq(struct malidp_hw_device *hwdev, int malidp_de_irq_init(struct drm_device *drm, int irq); void malidp_de_irq_fini(struct malidp_hw_device *hwdev); int malidp_se_irq_init(struct drm_device *drm, int irq); -void malidp_se_irq_fini(struct drm_device *drm); +void malidp_se_irq_fini(struct malidp_hw_device *hwdev); u8 malidp_hw_get_format_id(const struct malidp_hw_regmap *map, u8 layer_id, u32 format); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/8] drm/arm/malidp: Enable/disable interrupts in runtime pm
Display engine and core interrupts need to be disabled when the system invokes malidp_runtime_pm_suspend. Consequently, they need to be enabled in malidp_runtime_pm_resume. Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id --- drivers/gpu/drm/arm/malidp_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index f7a8beb..e5a1fa0 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -470,6 +470,7 @@ static int malidp_runtime_pm_suspend(struct device *dev) /* we can only suspend if the hardware is in config mode */ WARN_ON(!hwdev->hw->in_config_mode(hwdev)); + malidp_de_irq_fini(hwdev); hwdev->pm_suspended = true; clk_disable_unprepare(hwdev->mclk); clk_disable_unprepare(hwdev->aclk); @@ -488,6 +489,7 @@ static int malidp_runtime_pm_resume(struct device *dev) clk_prepare_enable(hwdev->aclk); clk_prepare_enable(hwdev->mclk); hwdev->pm_suspended = false; + malidp_de_irq_hw_init(hwdev); return 0; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/8] drm/arm/malidp: Split malidp_de_irq_init
Extract the hardware initialisation part from malidp_de_irq_init() into the malidp_de_irq_hw_init() which will be later invoked from runtime_pm_resume function when it needs to re-enable the interrupts. Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id --- drivers/gpu/drm/arm/malidp_hw.c | 25 ++--- drivers/gpu/drm/arm/malidp_hw.h | 1 + 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index 8fb02f3..3e73370 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -869,6 +869,23 @@ static irqreturn_t malidp_de_irq_thread_handler(int irq, void *arg) return IRQ_HANDLED; } +void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev) +{ + /* ensure interrupts are disabled */ + malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK, 0x); + malidp_hw_clear_irq(hwdev, MALIDP_DE_BLOCK, 0x); + malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK, 0x); + malidp_hw_clear_irq(hwdev, MALIDP_DC_BLOCK, 0x); + + /* first enable the DC block IRQs */ + malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK, +hwdev->hw->map.dc_irq_map.irq_mask); + + /* now enable the DE block IRQs */ + malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK, +hwdev->hw->map.de_irq_map.irq_mask); +} + int malidp_de_irq_init(struct drm_device *drm, int irq) { struct malidp_drm *malidp = drm->dev_private; @@ -889,13 +906,7 @@ int malidp_de_irq_init(struct drm_device *drm, int irq) return ret; } - /* first enable the DC block IRQs */ - malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK, -hwdev->hw->map.dc_irq_map.irq_mask); - - /* now enable the DE block IRQs */ - malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK, -hwdev->hw->map.de_irq_map.irq_mask); + malidp_de_irq_hw_init(hwdev); return 0; } diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h index 6607aba..3b049d0 100644 --- a/drivers/gpu/drm/arm/malidp_hw.h +++ b/drivers/gpu/drm/arm/malidp_hw.h @@ -297,6 +297,7 @@ static inline void malidp_hw_enable_irq(struct malidp_hw_device *hwdev, } int malidp_de_irq_init(struct drm_device *drm, int irq); +void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev); void malidp_de_irq_fini(struct malidp_hw_device *hwdev); int malidp_se_irq_init(struct drm_device *drm, int irq); void malidp_se_irq_fini(struct malidp_hw_device *hwdev); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/8] drm/arm/malidp: Set the output_depth register in modeset
One needs to store the value of the OUTPUT_DEPTH that one has parsed from device tree, so that it can be restored on system resume. This value is set in the modeset function as this gets reset when the system suspends. Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id --- drivers/gpu/drm/arm/malidp_drv.c | 1 + drivers/gpu/drm/arm/malidp_hw.c | 4 drivers/gpu/drm/arm/malidp_hw.h | 1 + 3 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index e5a1fa0..bd44a6d 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -601,6 +601,7 @@ static int malidp_bind(struct device *dev) for (i = 0; i < MAX_OUTPUT_CHANNELS; i++) out_depth = (out_depth << 8) | (output_width[i] & 0xf); malidp_hw_write(hwdev, out_depth, hwdev->hw->map.out_depth_base); + hwdev->output_color_depth = out_depth; atomic_set(&malidp->config_valid, 0); init_waitqueue_head(&malidp->wq); diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index 90d76e4..1bf10fb 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -234,6 +234,8 @@ static void malidp500_modeset(struct malidp_hw_device *hwdev, struct videomode * { u32 val = 0; + malidp_hw_write(hwdev, hwdev->output_color_depth, + hwdev->hw->map.out_depth_base); malidp_hw_clearbits(hwdev, MALIDP500_DC_CLEAR_MASK, MALIDP500_DC_CONTROL); if (mode->flags & DISPLAY_FLAGS_HSYNC_HIGH) val |= MALIDP500_HSYNCPOL; @@ -458,6 +460,8 @@ static void malidp550_modeset(struct malidp_hw_device *hwdev, struct videomode * { u32 val = MALIDP_DE_DEFAULT_PREFETCH_START; + malidp_hw_write(hwdev, hwdev->output_color_depth, + hwdev->hw->map.out_depth_base); malidp_hw_write(hwdev, val, MALIDP550_DE_CONTROL); /* * Mali-DP550 and Mali-DP650 encode the background color like this: diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h index 3b049d0..844732d 100644 --- a/drivers/gpu/drm/arm/malidp_hw.h +++ b/drivers/gpu/drm/arm/malidp_hw.h @@ -228,6 +228,7 @@ struct malidp_hw_device { u8 min_line_size; u16 max_line_size; + u32 output_color_depth; /* track the device PM state */ bool pm_suspended; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/8] drm/arm/malidp: Modified the prototype of malidp_de_irq_fini
'struct drm_device' is being replaced with 'struct malidp_hw_device' as the function argument. The reason being the dependency of malidp_de_irq_fini on 'struct drm_device' needs to be removed so as to enable it to call from functions which receives 'struct malidp_hw_device' as argument. Furthermore, there is no way to retrieve 'struct drm_device' from 'struct malidp_hw_device'. Signed-off-by: Ayan Kumar Halder --- Changes in v2:- - Removed the change id --- drivers/gpu/drm/arm/malidp_drv.c | 9 ++--- drivers/gpu/drm/arm/malidp_hw.c | 5 + drivers/gpu/drm/arm/malidp_hw.h | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 4b0c4b4..ed38ba9 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -295,6 +295,8 @@ static int malidp_irq_init(struct platform_device *pdev) { int irq_de, irq_se, ret = 0; struct drm_device *drm = dev_get_drvdata(&pdev->dev); + struct malidp_drm *malidp = drm->dev_private; + struct malidp_hw_device *hwdev = malidp->dev; /* fetch the interrupts from DT */ irq_de = platform_get_irq_byname(pdev, "DE"); @@ -314,7 +316,7 @@ static int malidp_irq_init(struct platform_device *pdev) ret = malidp_se_irq_init(drm, irq_se); if (ret) { - malidp_de_irq_fini(drm); + malidp_de_irq_fini(hwdev); return ret; } @@ -652,7 +654,7 @@ static int malidp_bind(struct device *dev) pm_runtime_get_sync(dev); vblank_fail: malidp_se_irq_fini(drm); - malidp_de_irq_fini(drm); + malidp_de_irq_fini(hwdev); drm->irq_enabled = false; irq_init_fail: component_unbind_all(dev, drm); @@ -681,6 +683,7 @@ static void malidp_unbind(struct device *dev) { struct drm_device *drm = dev_get_drvdata(dev); struct malidp_drm *malidp = drm->dev_private; + struct malidp_hw_device *hwdev = malidp->dev; drm_dev_unregister(drm); drm_fb_cma_fbdev_fini(drm); @@ -688,7 +691,7 @@ static void malidp_unbind(struct device *dev) pm_runtime_get_sync(dev); drm_crtc_vblank_off(&malidp->crtc); malidp_se_irq_fini(drm); - malidp_de_irq_fini(drm); + malidp_de_irq_fini(hwdev); drm->irq_enabled = false; component_unbind_all(dev, drm); of_node_put(malidp->crtc.port); diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index e4d9ebc..b13dfac 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -900,11 +900,8 @@ int malidp_de_irq_init(struct drm_device *drm, int irq) return 0; } -void malidp_de_irq_fini(struct drm_device *drm) +void malidp_de_irq_fini(struct malidp_hw_device *hwdev) { - struct malidp_drm *malidp = drm->dev_private; - struct malidp_hw_device *hwdev = malidp->dev; - malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK, hwdev->hw->map.de_irq_map.irq_mask); malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK, diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h index a242e97..6e2a2f6 100644 --- a/drivers/gpu/drm/arm/malidp_hw.h +++ b/drivers/gpu/drm/arm/malidp_hw.h @@ -297,7 +297,7 @@ static inline void malidp_hw_enable_irq(struct malidp_hw_device *hwdev, } int malidp_de_irq_init(struct drm_device *drm, int irq); -void malidp_de_irq_fini(struct drm_device *drm); +void malidp_de_irq_fini(struct malidp_hw_device *hwdev); int malidp_se_irq_init(struct drm_device *drm, int irq); void malidp_se_irq_fini(struct drm_device *drm); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/8] drm/arm/malidp: Enhance support for system and runtime power management on malidp.
This patch series enhances and fixes certain issues relevant to system and runtime power management on malidp. --- Changes in v2: - Removed the change ids and modified some commit messages --- Ayan Kumar Halder (8): drm/arm/malidp: Modified the prototype of malidp_de_irq_fini drm/arm/malidp: Modified the prototype of malidp_se_irq_fini drm/arm/malidp: Split malidp_de_irq_init drm/arm/malidp: Split malidp_se_irq_init drm/arm/malidp: Enable/disable interrupts in runtime pm drm/arm/malidp: Enable/disable the scaling engine interrupts with memory writeback drm/arm/malidp: Set the output_depth register in modeset drm/arm/malidp: Added the late system pm functions drivers/gpu/drm/arm/malidp_drv.c | 33 drivers/gpu/drm/arm/malidp_hw.c | 55 +++- drivers/gpu/drm/arm/malidp_hw.h | 6 +++-- 3 files changed, 70 insertions(+), 24 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal
https://bugs.freedesktop.org/show_bug.cgi?id=106191 --- Comment #6 from Alex Deucher --- Please attach your full dmesg output. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC for a render API to support adaptive sync and VRR
On 2018-04-20 04:32 PM, Manasi Navare wrote: > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: >>> Michel Dänzer writes: Time-based presentation seems to be the right approach for preventing micro-stutter in games as well, Croteam developers have been researching this. >>> >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present >>> extension offer the ability to specify the desired display time in >>> seconds. >>> >>> Similarly, I'd suggest that the min/max display refresh rate values be >>> advertised as time between frames rather than frames per second. > > So there is a global min and max refresh rate as advertised by the monitor > range descriptor. That I guess can be exposed as a global range in terms of > min and max time between frames as a global property of the connector. > > We dont need the per mode min and max refresh rate to be exposed right? If I understand VRR right, with CinemaVRR acceptable refresh rates might fall outside the range advertised by the monitor. Would we 1) advertise 24/1.001 as a lower bound, 2) expect media apps to use the lower bound simply for informational purposes, 3) or simply not support CinemaVRR? (1) has the added caveat that not all reported rates would be supported. Alternatively a bit could indicate that CinemaVRR is support, but I'm not sure if user mode would need all these details. Harry > >>> >>> I'd also encourage using a single unit for all of these values, >>> preferably nanoseconds. Absolute times should all be referenced to >>> CLOCK_MONOTONIC. >> >> +1 on everything Keith said. I got somehow dragged in khr vk >> discussions around preventing micro-stuttering, and consensus seems to >> be that timestamps for scheduling frames is the way to go, most likely >> absolute ones (not everything is running Linux unfortunately, so can't >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC). >> -Daniel > > And yes I also got consensus from Mesa and media folks about using the > absolute timestamp for scheduling the frames and then the driver will > modify the vblank logic to "present no earlier than the timestamp" > > Manasi > >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > 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
[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2
https://bugzilla.kernel.org/show_bug.cgi?id=199319 --- Comment #20 from har...@gmx.de --- This issues (both, the flickering and the black screen) are obviously fixed with kernel 4.17.0-rc2. Thank you. -- 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 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI
Hi, Il 22/03/2018 19:05, Maxime Ripard ha scritto: On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote: The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production label, is an industrial Human Machine Interface. It features: - 512MB DDR RAM - 1 Sd-card >= 4GB - 1 Usb otg(programmable via software) with A-Usb Connector - 1 Usb host - 1 Buzzer - 1 Input for LiPo - 1 Relay to signal absence of power supply - 1 External Rtc with 56 bytes of ram + CR2032 battery - 1 7" 24-bits Tft 800x480 with PCap on - 1 Mono audio 1-watt amplifier - 1 RS485 port - 1 Power On Line through +12Vdc reaching 57.600baud, from where it can be supplied and placed in a network of 50 units - exposed jtag pins HMI is supplied from +12Vdc. Ethernet is absent, so for debugging, need to enable rndis on Usb otg port through an A-A usb cable. It comes in different flavours for connector types and can be found with umounted features as requested by customers. So this is essentially the same board than in patch 6, but with a different screen? You should have a single DT then, and handle the two different panels using DT overlays. Ok for having different DT overlays. But do I have to submit them as patches? Or keep them in my company's repo? I ask you this because this involves sending also patches for displays and other little modifications to mainline ex: - rgb888 pins - 2 simple-panels - 1 uart iomux pins etc. If I don't submit those overlays, the other patches wouldn't make sense alone as I've seen, just like rgb888 pins. Signed-off-by: Giulio Benetti --- .../devicetree/bindings/arm/micronova.txt | 4 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 + 3 files changed, 197 insertions(+) create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt index 35c4127..9f5ac72 100644 --- a/Documentation/devicetree/bindings/arm/micronova.txt +++ b/Documentation/devicetree/bindings/arm/micronova.txt @@ -4,3 +4,7 @@ Micronova Device Tree Bindings A20-LiNova1-4_3 HMI Required root node properties: - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20"; + +A20-LiNova1-7 HMI +Required root node properties: +- compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20"; These bindings are unnecessary, but the panel-simple bindings should be sent to the DT maintainers as well. Ok, removed them and already sent the ones for display. diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index c45a4f25..eafa7cb 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \ sun7i-a20-m3.dtb \ sun7i-a20-mk808c.dtb \ sun7i-a20-linova1-ctp-4_3i.dtb\ + sun7i-a20-linova1-ctp-7i.dtb\ You should have a space after dtb, and it should be ordered alphabetically. Done. sun7i-a20-olimex-som-evb.dtb \ sun7i-a20-olinuxino-lime.dtb \ sun7i-a20-olinuxino-lime2.dtb \ diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts new file mode 100644 index 000..7fd0d98 --- /dev/null +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts @@ -0,0 +1,192 @@ +/* + * This is based on sun7i-a20-linova1-ctp-7i.dts + * + * Copyright 2014 - Hans de Goede + * Copyright (c) 2014 FUKAUMI Naoki + * Copyright (c) 2018 Giulio Benetti + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * inclu
[Bug 199475] AMDGPU Failed to blank
https://bugzilla.kernel.org/show_bug.cgi?id=199475 --- Comment #5 from DCWizard (andreas...@gmail.com) --- No i don't have any display problem. -- 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 199475] AMDGPU Failed to blank
https://bugzilla.kernel.org/show_bug.cgi?id=199475 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Other than the message, are you actually seeing any problem with the display? -- 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 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+
https://bugs.freedesktop.org/show_bug.cgi?id=106193 --- Comment #3 from Harry Wentland --- If the patch doesn't help are you able to capture the dmesg log and post it? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+
https://bugs.freedesktop.org/show_bug.cgi?id=106193 --- Comment #2 from Harry Wentland --- Created attachment 139013 --> https://bugs.freedesktop.org/attachment.cgi?id=139013&action=edit [PATCH] drm/amd/display: Disallow enabling CRTC without primary plane with FB Does this help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+
https://bugs.freedesktop.org/show_bug.cgi?id=106193 --- Comment #1 from Joel Sass --- Created attachment 139012 --> https://bugs.freedesktop.org/attachment.cgi?id=139012&action=edit A picture of the monitor output on failure. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep
https://bugs.freedesktop.org/show_bug.cgi?id=106192 Michel Dänzer changed: What|Removed |Added Attachment #139011|application/x-trash |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep
https://bugs.freedesktop.org/show_bug.cgi?id=106192 Michel Dänzer changed: What|Removed |Added Attachment #139009|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep
https://bugs.freedesktop.org/show_bug.cgi?id=106192 Michel Dänzer changed: What|Removed |Added Attachment #139008|application/x-trash |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/panel: otm8009a: fix backlight updates
Backlight updates was not working anymore since the good implementation of the dsi lpm mode in the dsi host driver. After a longer analysis, the backlight updates in dsi video mode require the dsi hs mode. Note: it is important to keep the dsi lpm mode for the rest of the driver as init sequence, sleep in/out... dsi commands work in lp mode. Signed-off-by: Philippe Cornu --- drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c index 90f1ae4af93c..0fd2e0144d2b 100644 --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c @@ -98,6 +98,20 @@ static void otm8009a_dcs_write_buf(struct otm8009a *ctx, const void *data, DRM_WARN("mipi dsi dcs write buffer failed\n"); } +static void otm8009a_dcs_write_buf_hs(struct otm8009a *ctx, const void *data, + size_t len) +{ + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev); + + /* data will be sent in dsi hs mode (ie. no lpm) */ + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM; + + otm8009a_dcs_write_buf(ctx, data, len); + + /* restore back the dsi lpm mode */ + dsi->mode_flags |= MIPI_DSI_MODE_LPM; +} + #define dcs_write_seq(ctx, seq...) \ ({ \ static const u8 d[] = { seq }; \ @@ -387,7 +401,7 @@ static int otm8009a_backlight_update_status(struct backlight_device *bd) */ data[0] = MIPI_DCS_SET_DISPLAY_BRIGHTNESS; data[1] = bd->props.brightness; - otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data)); + otm8009a_dcs_write_buf_hs(ctx, data, ARRAY_SIZE(data)); /* set Brightness Control & Backlight on */ data[1] = 0x24; @@ -399,7 +413,7 @@ static int otm8009a_backlight_update_status(struct backlight_device *bd) /* Update Brightness Control & Backlight */ data[0] = MIPI_DCS_WRITE_CONTROL_DISPLAY; - otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data)); + otm8009a_dcs_write_buf_hs(ctx, data, ARRAY_SIZE(data)); return 0; } -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote: > Ideally we should be able to build both drivers in the same kernel > (especially as modules). > > I was hoping that it could be fixed easily but then I discovered > the root source of the problem: > > drivers/gpu/drm/omapdrm/dss/display.o: In function > `omapdss_unregister_display': > display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first > defined here The main problem is that omapdrm and omapfb are two different drivers for the same HW. You need to pick one, even if we would change those functions and fix the link issue. At some point in time we could compile both as modules (but not built-in), but the only use for that was development/testing and in the end made our life more difficult. So, now you must fully disable one of them to enable the other. And, actually, we even have boot-time code, not included in the module itself, which gets enabled when omapdrm is enabled. While it's of course good to support COMPILE_TEST, if using COMPILE_TEST with omapfb is problematic, I'm not sure if it's worth to spend time on that. We should be moving away from omapfb to omapdrm. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/panel: otm8009a: use new backlight api
Use the new backlight api. Signed-off-by: Philippe Cornu --- drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 26 1 file changed, 9 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c index 4c638b7b9943..c2a71bd17e08 100644 --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c @@ -260,11 +260,7 @@ static int otm8009a_disable(struct drm_panel *panel) if (!ctx->enabled) return 0; /* This is not an issue so we return 0 here */ - /* Power off the backlight. Note: end-user still controls brightness */ - ctx->bl_dev->props.power = FB_BLANK_POWERDOWN; - ret = backlight_update_status(ctx->bl_dev); - if (ret) - return ret; + backlight_disable(ctx->bl_dev); ret = mipi_dsi_dcs_set_display_off(dsi); if (ret) @@ -338,12 +334,7 @@ static int otm8009a_enable(struct drm_panel *panel) if (ctx->enabled) return 0; - /* -* Power on the backlight. Note: end-user still controls brightness -* Note: ctx->prepared must be true before updating the backlight. -*/ - ctx->bl_dev->props.power = FB_BLANK_UNBLANK; - backlight_update_status(ctx->bl_dev); + backlight_enable(ctx->bl_dev); ctx->enabled = true; @@ -459,11 +450,14 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi) ctx->panel.dev = dev; ctx->panel.funcs = &otm8009a_drm_funcs; - ctx->bl_dev = backlight_device_register(dev_name(dev), dev, ctx, - &otm8009a_backlight_ops, NULL); + ctx->bl_dev = devm_backlight_device_register(dev, dev_name(dev), +dsi->host->dev, ctx, +&otm8009a_backlight_ops, +NULL); if (IS_ERR(ctx->bl_dev)) { - dev_err(dev, "failed to register backlight device\n"); - return PTR_ERR(ctx->bl_dev); + ret = PTR_ERR(ctx->bl_dev); + dev_err(dev, "failed to register backlight %d\n", ret); + return ret; } ctx->bl_dev->props.max_brightness = OTM8009A_BACKLIGHT_MAX; @@ -491,8 +485,6 @@ static int otm8009a_remove(struct mipi_dsi_device *dsi) mipi_dsi_detach(dsi); drm_panel_remove(&ctx->panel); - backlight_device_unregister(ctx->bl_dev); - return 0; } -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/panel: otm8009a: fix glitches by moving backlight enable to otm8009a_enable()
The backlight 1st update was in the otm8009a_prepare() function for a bad reason: backlight was not working in video mode and the otm8009a_prepare() is in command mode for the init sequence. As the backlight is now fixed (no lpm), it is good to put it back in the otm8009a_enable() function, avoiding also image glitches visible on some "slow" devices. Signed-off-by: Philippe Cornu --- drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c index 0fd2e0144d2b..de4a16d5275c 100644 --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c @@ -330,13 +330,6 @@ static int otm8009a_prepare(struct drm_panel *panel) ctx->prepared = true; - /* -* Power on the backlight. Note: end-user still controls brightness -* Note: ctx->prepared must be true before updating the backlight. -*/ - ctx->bl_dev->props.power = FB_BLANK_UNBLANK; - backlight_update_status(ctx->bl_dev); - return 0; } @@ -344,6 +337,16 @@ static int otm8009a_enable(struct drm_panel *panel) { struct otm8009a *ctx = panel_to_otm8009a(panel); + if (ctx->enabled) + return 0; + + /* +* Power on the backlight. Note: end-user still controls brightness +* Note: ctx->prepared must be true before updating the backlight. +*/ + ctx->bl_dev->props.power = FB_BLANK_UNBLANK; + backlight_update_status(ctx->bl_dev); + ctx->enabled = true; return 0; -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/panel: otm8009a: no message if probe success
Remove the message in case of probe success. This comes from a suggestion followed in the recent integration of the raydium rm68200 panel. Signed-off-by: Philippe Cornu --- drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c index de4a16d5275c..4c638b7b9943 100644 --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c @@ -14,8 +14,6 @@ #include #include -#define DRV_NAME "orisetech_otm8009a" - #define OTM8009A_BACKLIGHT_DEFAULT 240 #define OTM8009A_BACKLIGHT_MAX 255 @@ -461,7 +459,7 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi) ctx->panel.dev = dev; ctx->panel.funcs = &otm8009a_drm_funcs; - ctx->bl_dev = backlight_device_register(DRV_NAME "_backlight", dev, ctx, + ctx->bl_dev = backlight_device_register(dev_name(dev), dev, ctx, &otm8009a_backlight_ops, NULL); if (IS_ERR(ctx->bl_dev)) { dev_err(dev, "failed to register backlight device\n"); @@ -483,11 +481,6 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi) return ret; } - DRM_INFO(DRV_NAME "_panel %ux%u@%u %ubpp dsi %udl - ready\n", -default_mode.hdisplay, default_mode.vdisplay, -default_mode.vrefresh, -mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes); - return 0; } @@ -513,7 +506,7 @@ static struct mipi_dsi_driver orisetech_otm8009a_driver = { .probe = otm8009a_probe, .remove = otm8009a_remove, .driver = { - .name = DRV_NAME "_panel", + .name = "panel-orisetech-otm8009a", .of_match_table = orisetech_otm8009a_of_match, }, }; -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/panel: otm8009a: backlight fixes & improvements
This patch serie fixes 2 backlight issues and adds the new backlight api support. Philippe Cornu (4): drm/panel: otm8009a: fix backlight updates drm/panel: otm8009a: fix glitches by moving backlight enable to otm8009a_enable() drm/panel: otm8009a: no message if probe success drm/panel: otm8009a: use new backlight api drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 58 1 file changed, 30 insertions(+), 28 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+
https://bugs.freedesktop.org/show_bug.cgi?id=106193 Bug ID: 106193 Summary: When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+ Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: sass.j...@gmail.com I'm unable to position my monitors outside of an inline configuration. I have 5 monitors, and if I try to position one outside of an inline configuration with xrandr, it results in a hard lock. Steps to replicate the process: $ xrandr --fb 7680x2160 xrandr --screen 0 output shows that the virtual desktop is set to 7680x2160 $ xrandr --output DP-6 --pos 0x1080 At that point, mouse and keyboard become unresponsive. After about 30 seconds, monitor output shows artifacting. I'll see if I can post an image of what I see. It appears this also causes all network activity to stop. The system cannot be pinged, and SSH server stops functioning. Seems to have the same issues as https://bugs.freedesktop.org/show_bug.cgi?id=106159 which freezes the system when connecting or disconnecting a displayport cable. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: Don't pass the index to drm_property_add_enum()
Acked-by: Stanislav Lisovskiy Best Regards, Lisovskiy Stanislav Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo> From: Ville Syrjala [ville.syrj...@linux.intel.com] Sent: Friday, March 16, 2018 9:04 PM To: dri-devel@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org; Patrik Jakobsson; Ben Skeggs; nouv...@lists.freedesktop.org Subject: [PATCH] drm: Don't pass the index to drm_property_add_enum() From: Ville Syrjälä drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. Cc: Patrik Jakobsson Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_connector.c | 6 +++--- drivers/gpu/drm/drm_property.c| 27 +-- drivers/gpu/drm/gma500/cdv_device.c | 4 ++-- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +- drivers/gpu/drm/i915/intel_sdvo.c | 5 ++--- drivers/gpu/drm/nouveau/nouveau_display.c | 4 +--- include/drm/drm_property.h| 2 +- 7 files changed, 23 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index b3cde897cd80..dfc8ca1e9413 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1069,7 +1069,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev, goto nomem; for (i = 0; i < num_modes; i++) - drm_property_add_enum(dev->mode_config.tv_mode_property, i, + drm_property_add_enum(dev->mode_config.tv_mode_property, i, modes[i]); dev->mode_config.tv_brightness_property = @@ -1156,7 +1156,7 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector, { struct drm_device *dev = connector->dev; struct drm_property *scaling_mode_property; - int i, j = 0; + int i; const unsigned valid_scaling_mode_mask = (1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1; @@ -1177,7 +1177,7 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector, if (!(BIT(i) & scaling_mode_mask)) continue; - ret = drm_property_add_enum(scaling_mode_property, j++, + ret = drm_property_add_enum(scaling_mode_property, drm_scaling_mode_enum_list[i].type, drm_scaling_mode_enum_list[i].name); diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c index 8f4672daac7f..1f8031e30f53 100644 --- a/drivers/gpu/drm/drm_property.c +++ b/drivers/gpu/drm/drm_property.c @@ -169,9 +169,9 @@ struct drm_property *drm_property_create_enum(struct drm_device *dev, return NULL; for (i = 0; i < num_values; i++) { - ret = drm_property_add_enum(property, i, - props[i].type, - props[i].name); + ret = drm_property_add_enum(property, + props[i].type, + props[i].name); if (ret) { drm_property_destroy(dev, property); return NULL; @@ -209,7 +209,7 @@ struct drm_property *drm_property_create_bitmask(struct drm_device *dev, uint64_t supported_bits) { struct drm_property *property; - int i, ret, index = 0; + int i, ret; int num_values = hweight64(supported_bits); flags |= DRM_MODE_PROP_BITMASK; @@ -221,14 +221,9 @@ struct drm_property *drm_property_create_bitmask(struct drm_device *dev, if (!(supported_bits & (1ULL << props[i].type))) continue; - if (WARN_ON(index >= num_values)) { - drm_property_destroy(dev, property); - return NULL; - } - - ret = drm_property_add_enum(property, index++, - props[i].type, - props[i].name); + ret = drm_property_add_enum(property, + props[i].type, + props[i].name); if (ret) { drm_property_destroy(dev, property); return NULL; @@ -376,7 +371,6 @@ EXPORT_SYMBOL(drm_property_create_bool); /** * drm_property_add_enum - add a possible value to an enumeration property * @property: enumeration property to change - * @index: index of the new enumeration * @value: value of the new enumeration * @name: symbolic name of the new enumeration * @@ -388,10 +382,11 @@ EXPORT_SYMBOL(drm_property_create_
Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote: > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote: > > Add stubs for omapfb_dss.h, in the case it is included by > > some driver when CONFIG_FB_OMAP2 is not defined, with can > > happen on ARM when DRM_OMAP is not 'n'. > > > > That allows building such driver(s) with COMPILE_TEST. > > > > Signed-off-by: Mauro Carvalho Chehab > > This patch should be dropped (together with patch #6/7) as it was > superseded by a better solution suggested by Laurent: > > https://patchwork.kernel.org/patch/10325193/ > > ACK-ed by Tomi: > > https://www.spinics.net/lists/dri-devel/msg171918.html > > and already merged by you (commit 7378f1149884 "media: omap2: > omapfb: allow building it with COMPILE_TEST").. Hmm, I see now while this patch is still included: menuconfig FB_OMAP2 tristate "OMAP2+ frame buffer support" depends on FB depends on DRM_OMAP = n Ideally we should be able to build both drivers in the same kernel (especially as modules). I was hoping that it could be fixed easily but then I discovered the root source of the problem: drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display': display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here ... I need some more time to think about this.. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep
https://bugs.freedesktop.org/show_bug.cgi?id=106192 --- Comment #3 from Joel Sass --- Created attachment 139011 --> https://bugs.freedesktop.org/attachment.cgi?id=139011&action=edit Xorg.conf from frozen screen 0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep
https://bugs.freedesktop.org/show_bug.cgi?id=106192 --- Comment #2 from Joel Sass --- Created attachment 139010 --> https://bugs.freedesktop.org/attachment.cgi?id=139010&action=edit Dmesg shows kernel error after freezing. Had to acquire with ssh. Looks like a kernel bug issue. This [ 966.373770] BUG: unable to handle kernel paging request at b419820f3c60 [ 966.373776] IP: __ww_mutex_lock.isra.3+0x283/0x670 [ 966.373777] PGD 46ed48067 P4D 46ed48067 PUD 46ed49067 PMD 461fc5067 PTE 0 [ 966.373780] Oops: [#2] SMP PTI [ 966.373781] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc rfcomm ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bnep binfmt_misc btusb btrtl btbcm btintel bluetooth snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel ecdh_generic snd_hda_codec applesmc input_leds input_polldev intel_powerclamp coretemp snd_seq_midi snd_hda_core intel_cstate snd_seq_midi_event snd_hwdep snd_rawmidi snd_pcm snd_seq snd_seq_device snd_timer snd lpc_ich kvm_intel kvm irqbypass soundcore shpchp i5500_temp mac_hid ioatdma i7core_edac dca parport_pc ppdev lp parport autofs4 raid10 raid456 [ 966.373810] async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear amdkfd amd_iommu_v2 amdgpu chash i2c_algo_bit gpu_sched ttm hid_generic drm_kms_helper e1000e firewire_ohci syscopyarea sysfillrect usbhid sysimgblt ptp fb_sys_fops pata_acpi firewire_core crc_itu_t hid pps_core drm [ 966.373825] CPU: 4 PID: 3205 Comm: Xorg Tainted: G D W I 4.16.2+ #1 [ 966.373826] Hardware name: Apple Inc. MacPro4,1/Mac-F221BEC8, BIOS MP41.88Z.0081.B07.0910130729 10/13/09 [ 966.373828] RIP: 0010:__ww_mutex_lock.isra.3+0x283/0x670 [ 966.373828] RSP: 0018:b41982473870 EFLAGS: 00010282 [ 966.373829] RAX: b419820f3c58 RBX: 9735a1096830 RCX: 00e7 [ 966.373830] RDX: 9735a530be81 RSI: 97357cbbbe80 RDI: b41982473890 [ 966.373831] RBP: b419824738f0 R08: 9735a34ab080 R09: 9735a3ab0b80 [ 966.373831] R10: b41982473908 R11: 2800 R12: 0002 [ 966.373832] R13: 9735a1096828 R14: b419824739c8 R15: [ 966.373833] FS: 7faa1e832a00() GS:9735af30() knlGS: [ 966.373834] CS: 0010 DS: ES: CR0: 80050033 [ 966.373835] CR2: b419820f3c60 CR3: 000443164000 CR4: 06e0 [ 966.373836] Call Trace: [ 966.373839] __ww_mutex_lock_slowpath+0x16/0x20 [ 966.373840] ? __ww_mutex_lock_slowpath+0x16/0x20 [ 966.373841] ww_mutex_lock+0x5a/0x70 [ 966.373852] drm_modeset_lock+0x35/0xb0 [drm] [ 966.373858] drm_atomic_get_crtc_state+0x5b/0x110 [drm] [ 966.373865] drm_atomic_get_plane_state+0xec/0x110 [drm] [ 966.373870] restore_fbdev_mode_atomic+0xd5/0x200 [drm_kms_helper] [ 966.373873] restore_fbdev_mode+0x31/0x140 [drm_kms_helper] [ 966.373875] ? _cond_resched+0x19/0x40 [ 966.373878] drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper] [ 966.373881] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [ 966.373883] fb_set_var+0x19f/0x440 [ 966.373885] ? mem_cgroup_uncharge_list+0x69/0x90 [ 966.373888] fbcon_blank+0x2b7/0x3a0 [ 966.373891] do_unblank_screen+0xba/0x1b0 [ 966.373892] vt_ioctl+0x4e1/0x1150 [ 966.373894] ? jbd2_journal_stop+0xf6/0x3f0 [ 966.373896] tty_ioctl+0xf6/0x8c0 [ 966.373898] ? fsnotify_grab_connector+0x43/0x70 [ 966.373900] ? call_rcu_sched+0x17/0x20 [ 966.373901] do_vfs_ioctl+0xa8/0x630 [ 966.373903] ? __fput+0x193/0x220 [ 966.373904] SyS_ioctl+0x79/0x90 [ 966.373907] do_syscall_64+0x73/0x130 [ 966.373908] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 966.373909] RIP: 0033:0x7faa1c69bf47 [ 966.373910] RSP: 002b:7ffd3892b788 EFLAGS: 3246 ORIG_RAX: 0010 [ 966.373911] RAX: ffda RBX: 55aa519db820 RCX: 7faa1c69bf47 [ 966.373912] RDX: RSI: 4b3a RDI: 000a [ 966.373912] RBP: 7ffd3892b800 R08: 55aa5257a420 R09: 55aa5257a100 [ 966.373913] R10: 003a R11: 3246 R12: 7ffd3892b970 [ 966.373914] R13: 0001 R14: 0005 R15: 55aa519e5360 [ 966.373915] Code: cd 03 00 00 45 84 ff 0f 85 43 02 00 00 48 89 df e8 03 34 00 00 e9 39 ff ff ff 49 8b 45 20 48 85 c0 0f 84 38 03 00 00 49 8b 4e 08 <48> 8b 50 08 48 39 d1 0f 88 27 03 00 00 48 39 d1 75 09 49 39 c6 [ 966.373934] RIP: __ww_mutex_lock.isra.3+0x283/0x670 RSP: b41982473870 [ 966.373935] CR2: b419820f3c60 [ 966.373936] ---[ end trace 57a9c31f2648be5f ]--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.
[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep
https://bugs.freedesktop.org/show_bug.cgi?id=106192 --- Comment #1 from Joel Sass --- Created attachment 139009 --> https://bugs.freedesktop.org/attachment.cgi?id=139009&action=edit Xorg failure when screen was blanked in lightdm -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep
https://bugs.freedesktop.org/show_bug.cgi?id=106192 Bug ID: 106192 Summary: 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: sass.j...@gmail.com Created attachment 139008 --> https://bugs.freedesktop.org/attachment.cgi?id=139008&action=edit Initial boot - everything was fine. If I leave my computer at the logon screen and the monitors fall asleep, I cannot wake them. Requires a reboot. Looks like there was a dmesg error, and Xorg.0.log reflects a failure when attempting to use screen 0. I'll include the xorg.conf because that may have had something to do with it according to the Xorg.0.log. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI connector
Ping From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of StanLis [stanislav.lisovs...@intel.com] Sent: Monday, April 23, 2018 10:34 AM To: dri-devel@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI connector From: Stanislav Lisovskiy Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. Signed-off-by: Stanislav Lisovskiy --- Documentation/gpu/drm-kms.rst| 6 +++ Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/drm_atomic.c | 17 +++ drivers/gpu/drm/drm_connector.c | 74 drivers/gpu/drm/drm_edid.c | 2 + include/drm/drm_connector.h | 18 +++ include/drm/drm_mode_config.h| 5 ++ include/uapi/drm/drm_mode.h | 7 +++ 8 files changed, 130 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 1dffd1ac4cd4..e233c2626bd0 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -517,6 +517,12 @@ Standard Connector Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: standard connector properties +HDMI Specific Connector Properties +- + +.. kernel-doc:: drivers/gpu/drm/drm_connector.c + :doc: HDMI connector properties + Plane Composition Properties diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv index 6b28b014cb7d..3567c986bd7d 100644 --- a/Documentation/gpu/kms-properties.csv +++ b/Documentation/gpu/kms-properties.csv @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to suggest an X offset for a connector ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an Y offset for a connector ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", ""Cinema"", ""Game"" }",Connector,TBD i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255." ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 7d25c42f22db..479499f5848e 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector, state->link_status = val; } else if (property == config->aspect_ratio_property) { state->picture_aspect_ratio = val; + } else if (property == config->content_type_property) { + /* +* Lowest two bits of content_type property control +* content_type, bit 2 controls itc bit. +* It was decided to have a single property called +* content_type, instead of content_type and itc. +*/ + state->content_type = val & 3; + state->it_content = val >> 2; } else if (property == connector->scaling_mode_property) { state->scaling_mode = val; } else if (property == connector->content_protection_property) { @@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector *connector, *val = state->li
[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal
https://bugs.freedesktop.org/show_bug.cgi?id=106191 François Jacques changed: What|Removed |Added Summary|Failure to recognize|FirePro v8800 Failure to |DisplayPort signal |recognize DisplayPort ||signal -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106191] Failure to recognize DisplayPort signal
https://bugs.freedesktop.org/show_bug.cgi?id=106191 François Jacques changed: What|Removed |Added Keywords||have-backtrace -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel