Re: [PATCH v3] drm/bridge/sii8620: fix dependency on extcon
On 4/19/21 10:54 AM, Randy Dunlap wrote:
> On 4/19/21 10:10 AM, Randy Dunlap wrote:
>> On 4/19/21 2:01 AM, Robert Foss wrote:
>>> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
>>> on EXTCON, which causes issues when sii8620 is built
>>> as a builtin and EXTCON is built as a module.
>>>
>>> The symptoms are 'undefined reference' errors caused
>>> by the symbols in EXTCON not being available
>>> to the sii8620 driver.
>>>
>>> Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection
>>> logic to detect MHL")
>>> Signed-off-by: Robert Foss
>>> Reported-by: kernel test robot
>>> ---
>>>
>>> LKP reported issue:
>>> https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/
>>>
>>>
>>> Changes since v1:
>>> - Fix typo on comment
>>>
>>> Changes since v2:
>>> - Randy: Changed from `depends` to `select`
>>
>> I don't know why my name is on that. I didn't
>> suggest any change -- I just reported that v2
>> had a problem.
>>
>>
>>>
>>>
>>> drivers/gpu/drm/bridge/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>>> index 22a467abd3e9..70402da5cc70 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -169,7 +169,7 @@ config DRM_SIL_SII8620
>>> tristate "Silicon Image SII8620 HDMI/MHL bridge"
>>> depends on OF
>>> select DRM_KMS_HELPER
>>> - imply EXTCON
>>> + select EXTCON
>>> depends on RC_CORE || !RC_CORE
>>> help
>>> Silicon Image SII8620 HDMI/MHL bridge chip driver.
>>
>>
>> Thanks. Works For Me.
>>
>> Acked-by: Randy Dunlap # build-tested
>
> Actually I can upgrade that to:
>
> Reviewed-by: Randy Dunlap
Hi,
Is anyone merging this patch?
thanks.
--
~Randy
Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
On Fri, May 14, 2021 at 11:27 PM Steven Price wrote: > [snip] > >>> Seems this version is ready to be applied if we get a review on the DT ? > >>> > >>> Mathias ? could you have a look ? > >>> > >> > >> Given Rob has Acked the DT bindings, I think it's OK to apply patches > >> 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes. > >> > >> My two unsolicited cents :-) > > You make a convincing point - and if everyone is happy for the DT > changes to be handled separately I don't see a reason for the other > patches to be held up. > > > Yeah sure, is there a panfrost maintainer in the room ? I can apply them if > > you ack me. > > I seem to be applying most Panfrost changes these days, so I'll save you > the effort and push 1,3,4 to drm-misc-next. Thanks Steve!! > > Thanks, > > Steve
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On 2021/05/15 5:25, Maciej W. Rozycki wrote:
> NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO
> rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with
> it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is
> kind enough to know how to fiddle with its clockchip. It works just fine.
fbcon_update_vcs() from FBIOPUT_VSCREENINFO is no-op if vc->vc_mode != KD_TEXT
(which is equivalent to "if vc->vc_mode == KD_GRAPHICS" because
KD_TEXT0/KD_TEXT1
are treated as KD_TEXT). Then, maybe it is OK to let resize_screen() return
-EINVAL
in order to make vc_do_resize() request fail if vc->vc_mode == KD_GRAPHICS.
> Overall I think it does make sense to resize the text console at any
> time, even if the visible console (VT) chosen is in the graphics mode, as
> my understanding (and experience at least with vgacon) is that resizing
> the console applies globally across all the VTs. So the intent of the
> original change appears valid to me, and the choice not to reprogram the
> visible console and only store the settings for a future use if it's in
> the graphics mode correct.
>
> Which means any bug triggered here needs to be fixed elsewhere rather
> than by making the request fail.
Since syzbot does not trigger this problem with Linus's patch, I think we can
try Linus's patch with
pr_info_once("Resizing text console while in graphical mode is ignored.
Please report if you need this.\n");
added in order to see if somebody wants "only store the settings for a future
use".
Re: [PATCH v2] drm: rcar-du: fix linker undefined references
ping?
thanks.
On 4/23/21 5:12 PM, Randy Dunlap wrote:
> When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors
> as reported by 'kernel test robot'. These can be corrected by changing
> source code occurrences of IS_ENABLED(...) to IS_REACHABLE(...).
>
> In looking at this, the same problem (build errors) happens when
> DRM_RCAR_DU=y and DRM_RCAR_CMM=m, so again change an IS_ENABLED()
> to IS_REACHABLE() for this case as well.
>
> These changes fix the following 8 build/link errors:
>
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> `rcar_du_crtc_atomic_enable':
> rcar_du_crtc.c:(.text+0x1be8): undefined reference to `rcar_lvds_clk_enable'
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> `rcar_du_crtc_atomic_disable':
> rcar_du_crtc.c:(.text+0x2438): undefined reference to `rcar_lvds_clk_disable'
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function
> `rcar_du_init':
> rcar_du_drv.c:(.init.text+0x14): undefined reference to `rcar_du_of_init'
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in function
> `rcar_du_encoder_init':
> rcar_du_encoder.c:(.text+0x1d4): undefined reference to `rcar_lvds_dual_link'
>
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> `rcar_du_cmm_setup':
> rcar_du_crtc.c:(.text+0x380): undefined reference to `rcar_cmm_setup'
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> `rcar_du_crtc_atomic_enable':
> rcar_du_crtc.c:(.text+0x1c08): undefined reference to `rcar_cmm_enable'
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> `rcar_du_crtc_atomic_disable':
> rcar_du_crtc.c:(.text+0x231c): undefined reference to `rcar_cmm_disable'
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function
> `rcar_du_modeset_init':
> rcar_du_kms.c:(.text+0xd08): undefined reference to `rcar_cmm_init'
>
> All RCAR kconfig combinations now build for me.
>
> Fixes: e08e934d6c28 ("drm: rcar-du: Add support for CMM")
> Fixes: 02f2b30032c1 ("drm: rcar-du: lvds: Add API to enable/disable clock
> output")
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: Masahiro Yamada
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Jacopo Mondi
> ---
> v2: also send to LKML;
> don't change Kconfig "imply" to "select" since not all platforms
> with DU have CMM and/or LVDS support. Use IS_REACHABLE() instead.
>
> drivers/gpu/drm/rcar-du/rcar_cmm.h |4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_of.h |2 +-
> drivers/gpu/drm/rcar-du/rcar_lvds.h |2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> --- linux-next-20210420.orig/drivers/gpu/drm/rcar-du/rcar_lvds.h
> +++ linux-next-20210420/drivers/gpu/drm/rcar-du/rcar_lvds.h
> @@ -12,7 +12,7 @@
>
> struct drm_bridge;
>
> -#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS)
> +#if IS_REACHABLE(CONFIG_DRM_RCAR_LVDS)
> int rcar_lvds_clk_enable(struct drm_bridge *bridge, unsigned long freq);
> void rcar_lvds_clk_disable(struct drm_bridge *bridge);
> bool rcar_lvds_dual_link(struct drm_bridge *bridge);
> --- linux-next-20210420.orig/drivers/gpu/drm/rcar-du/rcar_du_of.h
> +++ linux-next-20210420/drivers/gpu/drm/rcar-du/rcar_du_of.h
> @@ -11,7 +11,7 @@
>
> struct of_device_id;
>
> -#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS)
> +#if IS_REACHABLE(CONFIG_DRM_RCAR_LVDS)
> void __init rcar_du_of_init(const struct of_device_id *of_ids);
> #else
> static inline void rcar_du_of_init(const struct of_device_id *of_ids) { }
> --- linux-next-20210420.orig/drivers/gpu/drm/rcar-du/rcar_cmm.h
> +++ linux-next-20210420/drivers/gpu/drm/rcar-du/rcar_cmm.h
> @@ -25,7 +25,7 @@ struct rcar_cmm_config {
> } lut;
> };
>
> -#if IS_ENABLED(CONFIG_DRM_RCAR_CMM)
> +#if IS_REACHABLE(CONFIG_DRM_RCAR_CMM)
> int rcar_cmm_init(struct platform_device *pdev);
>
> int rcar_cmm_enable(struct platform_device *pdev);
> @@ -53,6 +53,6 @@ static inline int rcar_cmm_setup(struct
> {
> return 0;
> }
> -#endif /* IS_ENABLED(CONFIG_DRM_RCAR_CMM) */
> +#endif /* IS_REACHABLE(CONFIG_DRM_RCAR_CMM) */
>
> #endif /* __RCAR_CMM_H__ */
>
--
~Randy
Re: [PATCH v3] drm: rcar: unbreak the R-Car menu items
ping? thanks. On 4/23/21 8:46 PM, Randy Dunlap wrote: > DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig > symbols do not depend on DRM_RCAR_DU, the menu presentation is > broken for the following R-Car Kconfig symbols. > > Use an if/endif block to make all of these symbols depend on > DRM_RCAR_DU (and remove the separate "depends on DRM_RCAR_DU"). > This makes the kconfig menu presentation much cleaner. > > Signed-off-by: Randy Dunlap > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: dri-devel@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: Koji Matsuoka > Cc: David Airlie > Cc: Geert Uytterhoeven > --- > v2: use an if/endif block for the dependencies (thanks, Geert) > v3: still applicable -- update/rebase > > Applies after today's earlier patch to fix undefined reference > build errors for R-Car (probably won't matter). > > I did this patch one year ago and then forgot about it somehow. > Rediscovered & updated it today. > > drivers/gpu/drm/rcar-du/Kconfig |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > --- linux-next-20210423.orig/drivers/gpu/drm/rcar-du/Kconfig > +++ linux-next-20210423/drivers/gpu/drm/rcar-du/Kconfig > @@ -14,10 +14,11 @@ config DRM_RCAR_DU > Choose this option if you have an R-Car chipset. > If M is selected the module will be called rcar-du-drm. > > +if DRM_RCAR_DU > + > config DRM_RCAR_CMM > tristate "R-Car DU Color Management Module (CMM) Support" > depends on DRM && OF > - depends on DRM_RCAR_DU > help > Enable support for R-Car Color Management Module (CMM). > > @@ -41,7 +42,6 @@ config DRM_RCAR_LVDS > config DRM_RCAR_VSP > bool "R-Car DU VSP Compositor Support" if ARM > default y if ARM64 > - depends on DRM_RCAR_DU > depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m) > help > Enable support to expose the R-Car VSP Compositor as KMS planes. > @@ -49,4 +49,5 @@ config DRM_RCAR_VSP > config DRM_RCAR_WRITEBACK > bool > default y if ARM64 > - depends on DRM_RCAR_DU > + > +endif # DRM_RCAR_DU > -- ~Randy
Re: [PATCH] drm/msm/dsi: save PLL registers across first PHY reset
Rob, On 07/10/2020 03:10, benl-kernelpatc...@squareup.com wrote: From: Benjamin Li Take advantage of previously-added support for persisting PLL registers across DSI PHY disable/enable cycles (see 328e1a6 'drm/msm/dsi: Save/Restore PLL status across PHY reset') to support persisting across the very first DSI PHY enable at boot. The bootloader may have left the PLL registers in a non-default state. For example, for dsi_pll_28nm.c on 8x16/8x39, the byte clock mux's power-on reset configuration is to bypass DIV1, but depending on bandwidth requirements[1] the bootloader may have set the DIV1 path. When the byte clock mux is registered with the generic clock framework at probe time, the framework reads & caches the value of the mux bit field (the initial clock parent). After PHY enable, when clk_set_rate is called on the byte clock, the framework assumes there is no need to reparent, and doesn't re-write the mux bit field. But PHY enable resets PLL registers, so the mux bit field actually silently reverted to the DIV1 bypass path. This causes the byte clock to be off by a factor of e.g. 2 for our tested WXGA panel. The above issue manifests as the display not working and a constant stream of FIFO/LP0 contention errors. [1] The specific requirement for triggering the DIV1 path (and thus this issue) on 28nm is a panel with pixel clock <116.7MHz (one-third the minimum VCO setting). FHD/1080p (~145MHz) is fine, WXGA/1280x800 (~75MHz) is not. This patch seems to be still relevant. Applying it would allow us to drop respective save_state calls from 10nm and 7nm drivers. I'd suggest applying it. Signed-off-by: Benjamin Li --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c index 009f5b843dd1..139b4a5aaf86 100644 --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -621,6 +621,22 @@ static int dsi_phy_driver_probe(struct platform_device *pdev) phy->pll = NULL; } + /* +* As explained in msm_dsi_phy_enable, resetting the DSI PHY (as done +* in dsi_mgr_phy_enable) silently changes its PLL registers to power-on +* defaults, but the generic clock framework manages and caches several +* of the PLL registers. It initializes these caches at registration +* time via register read. +* +* As a result, we need to save DSI PLL registers once at probe in order +* for the first call to msm_dsi_phy_enable to successfully bring PLL +* registers back in line with what the generic clock framework expects. +* +* Subsequent PLL restores during msm_dsi_phy_enable will always be +* paired with PLL saves in msm_dsi_phy_disable. +*/ + msm_dsi_pll_save_state(phy->pll); + dsi_phy_disable_resource(phy); platform_set_drvdata(pdev, phy); -- With best wishes Dmitry
[PATCH v3 1/1] drm/i915/dg1: Add HWMON power support
As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON entries are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. Signed-off-by: Dale B Stimson --- .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 799 ++ drivers/gpu/drm/i915/i915_hwmon.h | 44 + drivers/gpu/drm/i915/i915_reg.h | 53 ++ 8 files changed, 1023 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon new file mode 100644 index 0..2ee7c413ca190 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon @@ -0,0 +1,116 @@ +What: /sys/devices/.../hwmon/hwmon/energy1_input +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-devel@lists.freedesktop.org +Description: +RO. Energy input of device in microjoules. + + The returned textual representation is an unsigned integer + number that can be stored in 64-bits. Warning: The hardware + register is 32-bits wide and can overflow by wrapping around. + A single wrap-around between calls to read this value can + be detected and will be accounted for in the returned value. + At a power consumption of 1 watt, the 32-bit hardware register + would wrap-around approximately every 3 days. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-devel@lists.freedesktop.org +Description: +RW. Sustained power limit is enabled - true or false. + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-devel@lists.freedesktop.org +Description: +RW. Sustained power limit in milliwatts + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_interval +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-devel@lists.freedesktop.org +Description: +RW. Sustained power limit interval in milliseconds over +which sustained power is averaged. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-devel@lists.freedesktop.org +Description: + RW. Power burst limit is enabled - true or false + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-devel@lists.freedesktop.org +Description: + RW. Power burst limit in milliwatts. + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_default_limit +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-devel@lists.freedesktop.org +Description: +RO. Default power limit. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_min_limit +Date: June 2021 +KernelVersion: 5.14
[PATCH v3 0/1] drm/i915/dg1: Add HWMON power support
drm/i915/dg1: Add HWMON power support
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON entries are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
- power1_max
Some non-standard HWMON power information is also provided, such as
enable bits and intervals.
-
v3 Added documentation of these hwmon attributes in file
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
v3 Commit mesage minor rewording
v3 Function name changes:
i915_hwmon_init() -> i915_hwmon_register()
i915_hwmon_fini() -> i915_hwmon_unregister()
v3 i915_hwmon_register and i915_hwmon_unregister now take arg i915.
v3 i915_hwmon_register() now returns void instead of int.
v3 Macro FIELD_SHIFT() added to compute shift value from constant
field mask.
v3 Certain functions now longer require "inline" due to addition of new
parameter field_shift, allowing access to constant expressions for
the field mask at each call site. These functions now do field
access via shift and masking and no longer use le32*() functions
(as le32*() required a local constant expression for the mask).
_field_read_and_scale()
_field_read64_and_scale()
_field_scale_and_write()
v3 Some comments were modified.
v3 Now using sysfs_emit() instead of scnprintf().
V2 Rename local function parameter field_mask to field_msk in order to avoid
shadowing the name of function field_mask() from include/linux/bitfield.h.
V2 Change a comment introduction from "/**" to "/*", as it is not intended
to match a pattern that triggers documentation.
Reported-by: kernel test robot
V2 Slight movement of calls:
- i915_hwmon_init slightly later, after call to i915_setup_sysfs()
- i915_hwmon_fini slightly earlier, before i915_teardown_sysfs()
V2 Fixed some strong typing issues with le32 functions.
Detected by sparse in a run by kernel test robot:
Reported-by: kernel test robot
Dale B Stimson (1):
drm/i915/dg1: Add HWMON power support
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 6 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_hwmon.c | 799 ++
drivers/gpu/drm/i915/i915_hwmon.h | 44 +
drivers/gpu/drm/i915/i915_reg.h | 53 ++
8 files changed, 1023 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
Range-diff against v2:
1: 6e841c4d62a5a ! 1: afa81d35e1c55 drm/i915/dg1: Add HWMON power sensor
support
@@ Metadata
Author: Dale B Stimson
## Commit message ##
-drm/i915/dg1: Add HWMON power sensor support
+drm/i915/dg1: Add HWMON power support
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
-The following standard HWMON power sensors are currently supported
+The following standard HWMON entries are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
@@ drivers/gpu/drm/i915/i915_drv.c: static void i915_driver_register(struct
drm_i91
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
-+ /* Register with hwmon */
-+ if (i915_hwmon_init(_priv->drm))
-+ drm_err(_priv->drm, "Failed to register driver hwmon!\n");
++ i915_hwmon_register(dev_priv);
+
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
@@ drivers/gpu/drm/i915/i915_drv.c: static void
i915_driver_unregister(struct drm_i
i915_perf_unregister(dev_priv);
+
-+ i915_hwmon_fini(_priv->drm);
++ i915_hwmon_unregister(dev_priv);
+
i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
-+
- drm_dev_unplug(_priv->drm);
-
- i915_gem_driver_unregister(dev_priv);
## drivers/gpu/drm/i915/i915_drv.h ##
@@
@@ drivers/gpu/drm/i915/i915_drv.h: struct drm_i915_private {
## drivers/gpu/drm/i915/i915_hwmon.c (new) ##
@@
+// SPDX-License-Identifier: MIT
-+
+/*
+ * Copyright © 2020 Intel Corporation
+ */
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+#define SF_POWER 100
+#define SF_ENERGY 100
+
++#define FIELD_SHIFT(__mask) \
++ (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
++
[PATCH v2] drm/tegra: Get ref for DP AUX channel, not its ddc adapter
While we're taking a reference of the DDC adapter for a DP AUX channel in
tegra_sor_probe() because we're going to be using that adapter with the
SOR, now that we've moved where AUX registration happens the actual device
structure for the DDC adapter isn't initialized yet. Which means that we
can't really take a reference from it to try to keep it around anymore.
This should be fine though, because we can just take a reference of its
parent instead.
v2:
* Avoid calling i2c_put_adapter() in tegra_output_remove() for eDP/DP cases
Signed-off-by: Lyude Paul
Fixes: 39c17ae60ea9 ("drm/tegra: Don't register DP AUX channels before
connectors")
Cc: Lyude Paul
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/output.c | 5 -
drivers/gpu/drm/tegra/sor.c| 6 +++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 47d26b5d9945..2dacce1ab6ee 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -180,10 +180,13 @@ int tegra_output_probe(struct tegra_output *output)
void tegra_output_remove(struct tegra_output *output)
{
+ int connector_type = output->connector.connector_type;
+
if (output->hpd_gpio)
free_irq(output->hpd_irq, output);
- if (output->ddc)
+ if (connector_type != DRM_MODE_CONNECTOR_eDP &&
+ connector_type != DRM_MODE_CONNECTOR_DisplayPort && output->ddc)
i2c_put_adapter(output->ddc);
}
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 7b88261f57bb..4e0e3a63e586 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3739,11 +3739,11 @@ static int tegra_sor_probe(struct platform_device *pdev)
if (!sor->aux)
return -EPROBE_DEFER;
- if (get_device(>aux->ddc.dev)) {
- if (try_module_get(sor->aux->ddc.owner))
+ if (get_device(sor->aux->dev)) {
+ if (try_module_get(sor->aux->dev->driver->owner))
sor->output.ddc = >aux->ddc;
else
- put_device(>aux->ddc.dev);
+ put_device(sor->aux->dev);
}
}
--
2.31.1
Re: [PATCH] drm/msm/dsi: fix 32-bit clang warning
On Sat, 15 May 2021 at 00:31, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> clang is a little overzealous with warning about a constant conversion
> in an untaken branch of a ternary expression:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c:975:48: error: implicit conversion
> from 'unsigned long long' to 'unsigned long' changes value from 50 to
> 705032704 [-Werror,-Wconstant-conversion]
> .max_pll_rate = (50ULL < ULONG_MAX) ? 50UL :
> ULONG_MAX,
> ^~~~
>
> Rewrite this to use a preprocessor conditional instead to avoid the
> warning.
>
> Fixes: 076437c9e360 ("drm/msm/dsi: move min/max PLL rate to phy config")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Dmitry Baryshkov
> ---
> As found with another patch, using __builtin_choose_expr() would
> likely also work here, but doesn't seem any more readable.
> ---
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
> b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
> index e76ce40a12ab..accd6b4eb7c2 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
> @@ -972,7 +972,11 @@ const struct msm_dsi_phy_cfg dsi_phy_7nm_cfgs = {
> .restore_pll_state = dsi_7nm_pll_restore_state,
> },
> .min_pll_rate = 6UL,
> - .max_pll_rate = (50ULL < ULONG_MAX) ? 50ULL :
> ULONG_MAX,
> +#ifdef CONFIG_64BIT
> + .max_pll_rate = 50UL,
> +#else
> + .max_pll_rate = ULONG_MAX,
> +#endif
> .io_start = { 0xae94400, 0xae96400 },
> .num_dsi_phy = 2,
> .quirks = DSI_PHY_7NM_QUIRK_V4_1,
> --
> 2.29.2
>
--
With best wishes
Dmitry
Re: [PATCH] drm/msm/dsi: fix 32-bit clang warning
On 5/14/2021 2:30 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
clang is a little overzealous with warning about a constant conversion
in an untaken branch of a ternary expression:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c:975:48: error: implicit conversion
from 'unsigned long long' to 'unsigned long' changes value from 50 to
705032704 [-Werror,-Wconstant-conversion]
.max_pll_rate = (50ULL < ULONG_MAX) ? 50UL : ULONG_MAX,
^~~~
Rewrite this to use a preprocessor conditional instead to avoid the
warning.
Fixes: 076437c9e360 ("drm/msm/dsi: move min/max PLL rate to phy config")
Signed-off-by: Arnd Bergmann
Reviewed-by: Nathan Chancellor
---
As found with another patch, using __builtin_choose_expr() would
likely also work here, but doesn't seem any more readable.
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
index e76ce40a12ab..accd6b4eb7c2 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
@@ -972,7 +972,11 @@ const struct msm_dsi_phy_cfg dsi_phy_7nm_cfgs = {
.restore_pll_state = dsi_7nm_pll_restore_state,
},
.min_pll_rate = 6UL,
- .max_pll_rate = (50ULL < ULONG_MAX) ? 50ULL : ULONG_MAX,
+#ifdef CONFIG_64BIT
+ .max_pll_rate = 50UL,
+#else
+ .max_pll_rate = ULONG_MAX,
+#endif
.io_start = { 0xae94400, 0xae96400 },
.num_dsi_phy = 2,
.quirks = DSI_PHY_7NM_QUIRK_V4_1,
[PATCH] fbdev: matrox: use modern module_init()
From: Arnd Bergmann
This is one of the last drivers with a global init_module() function
instead of the modern module_init() annotation. Convert it over.
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/matrox/matroxfb_base.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 4325bf7f388c..5c82611e93d9 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -2486,8 +2486,6 @@ static int __init matroxfb_init(void)
return err;
}
-module_init(matroxfb_init);
-
#else
/* *** init module code */
@@ -2572,7 +2570,7 @@ module_param_named(cmode, default_cmode, int, 0);
MODULE_PARM_DESC(cmode, "Specify the video depth that should be used (8bit
default)");
#endif
-int __init init_module(void){
+static int __init matroxfb_init(void){
DBG(__func__)
@@ -2603,6 +2601,7 @@ int __init init_module(void){
}
#endif /* MODULE */
+module_init(matroxfb_init);
module_exit(matrox_done);
EXPORT_SYMBOL(matroxfb_register_driver);
EXPORT_SYMBOL(matroxfb_unregister_driver);
--
2.29.2
[PATCH] drm/msm/dsi: fix 32-bit clang warning
From: Arnd Bergmann
clang is a little overzealous with warning about a constant conversion
in an untaken branch of a ternary expression:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c:975:48: error: implicit conversion
from 'unsigned long long' to 'unsigned long' changes value from 50 to
705032704 [-Werror,-Wconstant-conversion]
.max_pll_rate = (50ULL < ULONG_MAX) ? 50UL : ULONG_MAX,
^~~~
Rewrite this to use a preprocessor conditional instead to avoid the
warning.
Fixes: 076437c9e360 ("drm/msm/dsi: move min/max PLL rate to phy config")
Signed-off-by: Arnd Bergmann
---
As found with another patch, using __builtin_choose_expr() would
likely also work here, but doesn't seem any more readable.
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
index e76ce40a12ab..accd6b4eb7c2 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
@@ -972,7 +972,11 @@ const struct msm_dsi_phy_cfg dsi_phy_7nm_cfgs = {
.restore_pll_state = dsi_7nm_pll_restore_state,
},
.min_pll_rate = 6UL,
- .max_pll_rate = (50ULL < ULONG_MAX) ? 50ULL : ULONG_MAX,
+#ifdef CONFIG_64BIT
+ .max_pll_rate = 50UL,
+#else
+ .max_pll_rate = ULONG_MAX,
+#endif
.io_start = { 0xae94400, 0xae96400 },
.num_dsi_phy = 2,
.quirks = DSI_PHY_7NM_QUIRK_V4_1,
--
2.29.2
Re: [PATCH] drm/amdgpu: Fix GPU TLB update error when PAGE_SIZE > AMDGPU_PAGE_SIZE
Applied. Thanks! Alex On Fri, May 14, 2021 at 3:18 AM Christian König wrote: > > Am 14.05.21 um 08:40 schrieb Huacai Chen: > > From: Yi Li > > > > When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB > > entries which need to update in amdgpu_map_buffer() should be multiplied > > by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE). > > > > Signed-off-by: Yi Li > > Signed-off-by: Huacai Chen > > Reviewed-by: Christian König > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > index 3bef0432cac2..a376a993e474 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > @@ -225,7 +225,7 @@ static int amdgpu_ttm_map_buffer(struct > > ttm_buffer_object *bo, > > *addr += mm_cur->start & ~PAGE_MASK; > > > > num_dw = ALIGN(adev->mman.buffer_funcs->copy_num_dw, 8); > > - num_bytes = num_pages * 8; > > + num_bytes = num_pages * 8 * AMDGPU_GPU_PAGES_IN_CPU_PAGE; > > > > r = amdgpu_job_alloc_with_ib(adev, num_dw * 4 + num_bytes, > >AMDGPU_IB_POOL_DELAYED, ); > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 1:32 PM Linus Torvalds wrote: > > Another alternative would be to just delay the resize to when vcmode > is put back to text mode again. That sounds somewhat reasonable to me, > but it's a pretty big thing. Actually thinking more about that option, it sounds horrible. It would mean that we'd continue to use the old geometry for the actual VC buffers for a random time, and then change it to the new geometry at some arbitrary point. So I think the only reasonable approach (apart from just my "don't do that then") might be to just always call ->con_resize(). There are only actually three cases of "->con_resize()", so it might not be too bad. Looking at it, both sisusbcon_resize() and vgacon_resize() seem to be trivially fine in KD_GRAPHICS mode. vgacon already seems to have that "!vga_is_gfx" test, and does vgacon_doresize() at vgacon_switch(). It might need to add a vgacon_doresize() to the vgacon_blank() case 0 code so that it actually does the right thing when going back to KD_TEXT mode. And fbcon_resize() looks like it might be mostly ok with it too. Again, there is a con_is_visible() test, and I suspect that might need to be changed to if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) instead, but it doesn't look _too_ bad. So I think just removing the "vc->vc_mode != KD_GRAPHICS" test from resize_screen() might be the way to go. That way, the low-level data structures actually are in sync with the resize, and the "out of bounds" bug should never happen. Would you mind testing that? Linus
[RFC PATCH v2 5/6] drm/color: Add color space plane property
From: Bhawanpreet Lakha Add color space definitions for BT601, BT709, BT2020, and DCI-P3. Default to BT709, the sRGB color space. Signed-off-by: Bhawanpreet Lakha Signed-off-by: Harry Wentland --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 + .../gpu/drm/arm/display/komeda/komeda_plane.c | 2 + drivers/gpu/drm/arm/malidp_planes.c | 4 +- drivers/gpu/drm/armada/armada_overlay.c | 2 + drivers/gpu/drm/drm_color_mgmt.c | 58 ++- drivers/gpu/drm/i915/display/intel_sprite.c | 2 + .../drm/i915/display/skl_universal_plane.c| 2 + drivers/gpu/drm/nouveau/dispnv04/overlay.c| 2 + drivers/gpu/drm/omapdrm/omap_plane.c | 2 + drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 6 +- drivers/gpu/drm/tidss/tidss_plane.c | 4 ++ include/drm/drm_color_mgmt.h | 16 + include/drm/drm_plane.h | 16 + 13 files changed, 113 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 59d277c31864..14e5260a298f 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7072,8 +7072,10 @@ static int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm, BIT(DRM_COLOR_YCBCR_BT2020), BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | BIT(DRM_COLOR_YCBCR_FULL_RANGE), + BIT(DRM_COLOR_SPACE_BT709), BIT(DRM_TF_SRGB), DRM_COLOR_YCBCR_BT709, DRM_COLOR_YCBCR_LIMITED_RANGE, + DRM_COLOR_SPACE_BT709, DRM_TF_SRGB); } diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c index 811f79ab6d32..4fb3ad4c691e 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c @@ -302,9 +302,11 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, BIT(DRM_COLOR_YCBCR_BT2020), BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | BIT(DRM_COLOR_YCBCR_FULL_RANGE), + BIT(DRM_COLOR_SPACE_BT709), BIT(DRM_TF_UNDEFINED), DRM_COLOR_YCBCR_BT601, DRM_COLOR_YCBCR_LIMITED_RANGE, + DRM_COLOR_SPACE_BT709, DRM_TF_UNDEFINED); if (err) goto cleanup; diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c index 8be0d40db2e5..6478b5b1bcf6 100644 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@ -1018,6 +1018,7 @@ int malidp_de_planes_init(struct drm_device *drm) /* default encoding for YUV->RGB is BT601 NARROW */ enum drm_color_encoding enc = DRM_COLOR_YCBCR_BT601; enum drm_color_range range = DRM_COLOR_YCBCR_LIMITED_RANGE; + enum drm_color_space space = DRM_COLOR_SPACE_BT709; ret = drm_plane_create_color_properties(>base, BIT(DRM_COLOR_YCBCR_BT601) | \ @@ -1025,8 +1026,9 @@ int malidp_de_planes_init(struct drm_device *drm) BIT(DRM_COLOR_YCBCR_BT2020), BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | \ BIT(DRM_COLOR_YCBCR_FULL_RANGE), + BIT(DRM_COLOR_SPACE_BT709), BIT(DRM_TF_UNDEFINED), - enc, range, + enc, range, space, DRM_TF_UNDEFINED); if (!ret) /* program the HW registers */ diff --git a/drivers/gpu/drm/armada/armada_overlay.c b/drivers/gpu/drm/armada/armada_overlay.c index f7792444cb73..e66f2fa72830 100644 --- a/drivers/gpu/drm/armada/armada_overlay.c +++ b/drivers/gpu/drm/armada/armada_overlay.c @@ -596,9 +596,11 @@ int armada_overlay_plane_create(struct drm_device *dev, unsigned long crtcs) BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709), BIT(DRM_COLOR_YCBCR_LIMITED_RANGE), + BIT(DRM_COLOR_SPACE_BT709), BIT(DRM_TF_UNDEFINED), DEFAULT_ENCODING, DRM_COLOR_YCBCR_LIMITED_RANGE, +
[RFC PATCH v2 3/6] drm/color: Add output transfer function to crtc
We currently have 1D LUTs to define output transfer function but using a
1D LUT is not always the best way to define a transfer function for HW
that has ROMs for certain transfer functions, or for HW that has complex
PWL definition for accurate LUT definitions.
For this reason we're introducing named transfer functions. The original
LUT behavior is preserved with the default "1D LUT" transfer function.
Signed-off-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++-
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
drivers/gpu/drm/arm/malidp_crtc.c | 7 ++-
drivers/gpu/drm/armada/armada_crtc.c | 5 +-
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 7 ++-
drivers/gpu/drm/drm_color_mgmt.c | 54 ---
drivers/gpu/drm/i915/display/intel_color.c| 11 ++--
drivers/gpu/drm/i915/display/intel_color.h| 2 +-
drivers/gpu/drm/i915/display/intel_crtc.c | 4 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 +++-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +++-
drivers/gpu/drm/nouveau/dispnv50/head.c | 13 +++--
drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +++-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 7 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +-
drivers/gpu/drm/stm/ltdc.c| 8 ++-
drivers/gpu/drm/tidss/tidss_crtc.c| 9 +++-
drivers/gpu/drm/vc4/vc4_crtc.c| 16 +-
include/drm/drm_color_mgmt.h | 37 +++--
include/drm/drm_crtc.h| 20 +++
21 files changed, 208 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 041576945a0d..59d277c31864 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7139,8 +7139,15 @@ static int amdgpu_dm_crtc_init(struct
amdgpu_display_manager *dm,
acrtc->otg_inst = -1;
dm->adev->mode_info.crtcs[crtc_index] = acrtc;
- drm_crtc_enable_color_mgmt(>base, MAX_COLOR_LUT_ENTRIES,
- true, MAX_COLOR_LUT_ENTRIES);
+
+ res = drm_crtc_enable_color_mgmt(>base, MAX_COLOR_LUT_ENTRIES,
+true, MAX_COLOR_LUT_ENTRIES,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (res) {
+ drm_crtc_cleanup(>base);
+ goto fail;
+ }
+
drm_mode_crtc_set_gamma_size(>base,
MAX_COLOR_LEGACY_LUT_ENTRIES);
return 0;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..f364d37232b5 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -626,7 +626,12 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
crtc->port = kcrtc->master->of_output_port;
- drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
+ err = drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (err) {
+ drm_crtc_cleanup(crtc);
+ return err;
+ }
return err;
}
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 494075ddbef6..7af87002c375 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -552,7 +552,12 @@ int malidp_crtc_init(struct drm_device *drm)
drm_crtc_helper_add(>crtc, _crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(>crtc, MALIDP_GAMMA_LUT_SIZE);
/* No inverse-gamma: it is per-plane. */
- drm_crtc_enable_color_mgmt(>crtc, 0, true,
MALIDP_GAMMA_LUT_SIZE);
+ ret = drm_crtc_enable_color_mgmt(>crtc, 0, true,
MALIDP_GAMMA_LUT_SIZE,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (ret) {
+ drm_crtc_cleanup(>crtc);
+ return ret;
+ }
malidp_se_set_enh_coeffs(malidp->dev);
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index b7bb90ae787f..d44a1d4fa475 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -992,7 +992,10 @@ static int armada_drm_crtc_create(struct drm_device *drm,
struct device *dev,
if (ret)
return ret;
- drm_crtc_enable_color_mgmt(>crtc, 0, false, 256);
+ ret = drm_crtc_enable_color_mgmt(>crtc, 0, false, ,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (ret)
+ return ret;
return armada_overlay_plane_create(drm, 1 << dcrtc->num);
diff --git
[RFC PATCH v2 6/6] drm/amd/display: reformat YCbCr-RGB conversion matrix
Show the CSC matrixes in a 4x3 format.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 28 +
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index ddbe4bb52724..e91dd899ba65 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -49,22 +49,30 @@ struct dpp_input_csc_matrix {
static const struct dpp_input_csc_matrix __maybe_unused dpp_input_csc_matrix[]
= {
{COLOR_SPACE_SRGB,
- {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
+ {0x2000, 0, 0, 0,
+ 0, 0x2000, 0, 0,
+ 0, 0, 0x2000, 0} },
{COLOR_SPACE_SRGB_LIMITED,
- {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
+ {0x2000, 0, 0, 0,
+ 0, 0x2000, 0, 0,
+ 0, 0, 0x2000, 0} },
{COLOR_SPACE_YCBCR601,
- {0x2cdd, 0x2000, 0, 0xe991, 0xe926, 0x2000, 0xf4fd, 0x10ef,
- 0, 0x2000, 0x38b4, 0xe3a6} },
+ {0x2cdd, 0x2000, 0, 0xe991,
+0xe926, 0x2000, 0xf4fd, 0x10ef,
+ 0, 0x2000, 0x38b4, 0xe3a6} },
{COLOR_SPACE_YCBCR601_LIMITED,
- {0x3353, 0x2568, 0, 0xe400, 0xe5dc, 0x2568, 0xf367, 0x1108,
- 0, 0x2568, 0x40de, 0xdd3a} },
+ {0x3353, 0x2568, 0, 0xe400,
+0xe5dc, 0x2568, 0xf367, 0x1108,
+ 0, 0x2568, 0x40de, 0xdd3a} },
{COLOR_SPACE_YCBCR709,
- {0x3265, 0x2000, 0, 0xe6ce, 0xf105, 0x2000, 0xfa01, 0xa7d, 0,
- 0x2000, 0x3b61, 0xe24f} },
+ {0x3265, 0x2000, 0, 0xe6ce,
+0xf105, 0x2000, 0xfa01, 0xa7d,
+ 0, 0x2000, 0x3b61, 0xe24f} },
{COLOR_SPACE_YCBCR709_LIMITED,
- {0x39a6, 0x2568, 0, 0xe0d6, 0xeedd, 0x2568, 0xf925, 0x9a8, 0,
- 0x2568, 0x43ee, 0xdbb2} }
+ {0x39a6, 0x2568, 0, 0xe0d6,
+0xeedd, 0x2568, 0xf925, 0x9a8,
+ 0, 0x2568, 0x43ee, 0xdbb2} }
};
struct dpp_grph_csc_adjustment {
--
2.31.1
[RFC PATCH v2 2/6] drm/color: Add transfer functions for HDR/SDR on drm_plane
From: Bhawanpreet Lakha Due to the way displays and human vision work it is most effective to encode luminance information in a non-linear space. For SDR this non-linear mapping is assumed to roughly use a gamma 2.2 curve. This was due to the way CRTs worked and was fine for SDR content with a low luminance range. The large luminance range (0-10,000 nits) for HDR exposes some short-comings of a simple gamma curve that have been addressed through various Electro-Optical Transfer Functions (EOTFs). Rather than assuming how framebuffer content is encoded we want to make sure userspace presenting HDR content is explicit about the EOTF of the content, so a driver can decide whether the content can be supported or not. This Patch adds common transfer functions for SDR/HDR. These can be used to communicate with the driver regarding the transformation to use for a given plane. enums added: DRM_TF_UNDEFINED the legacy case where the TF in/out of blending space is undefined DRM_TF_SRGB roughly 2.4 gamma with initial linear section DRM_TF_BT709 Similar to Gamma 2.2-2.8 DRM_TF_PQ2084 most common tf used for HDR video (HDR10/Dolby). Can support up to 10,000 nits The usage is similar to color_encoding and color_range where the driver can specify the default and supported tfs and pass it into drm_plane_create_color_properties(). v2: - drop "color" from transfer function name (Harry) - add DRM_TF_UNDEFINED enum as legacy default (Harry) Signed-off-by: Bhawanpreet Lakha Signed-off-by: Harry Wentland --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +- .../gpu/drm/arm/display/komeda/komeda_plane.c | 4 +- drivers/gpu/drm/arm/malidp_planes.c | 4 +- drivers/gpu/drm/armada/armada_overlay.c | 4 +- drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_color_mgmt.c | 64 +-- drivers/gpu/drm/i915/display/intel_sprite.c | 4 +- .../drm/i915/display/skl_universal_plane.c| 4 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c| 4 +- drivers/gpu/drm/omapdrm/omap_plane.c | 4 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 4 +- drivers/gpu/drm/tidss/tidss_plane.c | 6 +- include/drm/drm_color_mgmt.h | 18 +- include/drm/drm_plane.h | 16 + 14 files changed, 128 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 389eff96fcf6..041576945a0d 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7072,7 +7072,9 @@ static int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm, BIT(DRM_COLOR_YCBCR_BT2020), BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | BIT(DRM_COLOR_YCBCR_FULL_RANGE), - DRM_COLOR_YCBCR_BT709, DRM_COLOR_YCBCR_LIMITED_RANGE); + BIT(DRM_TF_SRGB), + DRM_COLOR_YCBCR_BT709, DRM_COLOR_YCBCR_LIMITED_RANGE, + DRM_TF_SRGB); } supported_rotations = diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c index d63d83800a8a..811f79ab6d32 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c @@ -302,8 +302,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, BIT(DRM_COLOR_YCBCR_BT2020), BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | BIT(DRM_COLOR_YCBCR_FULL_RANGE), + BIT(DRM_TF_UNDEFINED), DRM_COLOR_YCBCR_BT601, - DRM_COLOR_YCBCR_LIMITED_RANGE); + DRM_COLOR_YCBCR_LIMITED_RANGE, + DRM_TF_UNDEFINED); if (err) goto cleanup; diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c index ddbba67f0283..8be0d40db2e5 100644 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@ -1025,7 +1025,9 @@ int malidp_de_planes_init(struct drm_device *drm) BIT(DRM_COLOR_YCBCR_BT2020), BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | \ BIT(DRM_COLOR_YCBCR_FULL_RANGE), - enc, range); + BIT(DRM_TF_UNDEFINED), + enc, range, + DRM_TF_UNDEFINED); if (!ret) /* program the HW registers */
[RFC PATCH v2 4/6] drm/color: Add sdr boost property
From: Bhawanpreet Lakha
SDR is typically mastered at 200 nits and HDR is mastered at up to 10,000
nits. Due to this luminance range difference if we blend a SDR and
HDR plane together, we can run into problems where the HDR plane is too
bright or the SDR plane is too dim
A common solution to this problem is to boost the SDR plane so that its
not too dim.
This patch introduces a "sdr_white_level" property, this property can be
used by the userspace to boost the SDR content luminance. The boost
value is an explicit luminance value in nits. This allows the userspace
to set the maximum white level for the SDR plane.
v2:
- fix type in description
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_color_mgmt.c | 17 +
include/drm/drm_color_mgmt.h | 6 ++
include/drm/drm_plane.h | 15 ++-
4 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 42f8fd577d36..863d6ee3bd3d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -597,6 +597,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->color_range = val;
} else if (property == plane->transfer_function_property) {
state->transfer_function = val;
+ } else if (property == plane->sdr_white_level_property) {
+ state->sdr_white_level = val;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>fb_damage_clips,
@@ -665,6 +667,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_range;
} else if (property == plane->transfer_function_property) {
*val = state->transfer_function;
+ } else if (property == plane->sdr_white_level_property) {
+ *val = state->sdr_white_level;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 196544951ab7..44842ba0454d 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -556,6 +556,23 @@ const char *drm_get_color_range_name(enum drm_color_range
range)
return color_range_name[range];
}
+int drm_plane_create_sdr_white_level_property(struct drm_plane *plane){
+
+ struct drm_property *prop;
+
+ prop = drm_property_create_range(plane->dev, 0, "SDR_WHITE_LEVEL", 0,
UINT_MAX);
+
+ if (!prop)
+ return -ENOMEM;
+
+ plane->sdr_white_level_property = prop;
+ drm_object_attach_property(>base, prop,
DRM_DEFAULT_SDR_WHITE_LEVEL);
+
+ if (plane->state)
+ plane->state->sdr_white_level = DRM_DEFAULT_SDR_WHITE_LEVEL;
+
+ return 0;
+}
/**
* drm_get_transfer_function - return a string for transfer function
* @tf: transfer function to compute name of
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 408561acdb3d..2a356a9601df 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -26,6 +26,12 @@
#include
#include
+/**
+ * Default SDR white level in nits. Although there is no standard SDR nit
level, 200
+ * is chosen as the default since that is the generally accepted value.
+ */
+#define DRM_DEFAULT_SDR_WHITE_LEVEL 200
+
struct drm_crtc;
struct drm_plane;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index cff56994513f..93ee308a46af 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -187,6 +187,11 @@ struct drm_plane_state {
* format for a proper HDR color/luminance output.
*/
enum drm_transfer_function transfer_function;
+ /**
+* @sdr_white_level:
+* SDR white level boost for HDR+SDR multi plane usecases. max white
level in nits
+*/
+ unsigned int sdr_white_level;
/**
* @fb_damage_clips:
*
@@ -757,7 +762,15 @@ struct drm_plane {
* See drm_plane_create_color_properties().
*/
struct drm_property *transfer_function_property;
-
+ /**
+* @sdr_white_level:
+*
+* Optional sdr_white_level. When HDR and SDR are combined in multi
plane
+* overlay cases, the sdr plane will be very dim. This property allows
+* the driver to boost the sdr plane's white level. The value should be
+* max white level in nits.
+*/
+ struct drm_property *sdr_white_level_property;
/**
* @scaling_filter_property: property to apply a particular filter while
* scaling.
--
2.31.1
[RFC PATCH v2 1/6] drm/doc: Color Management and HDR10 RFC
Use the new DRM RFC doc section to capture the RFC previously only described in the cover letter at https://patchwork.freedesktop.org/series/89506/ Update the RFC based on feedback received: * don't use color_encoding property to define color space * expand on reason for SDR luminance definition * define input/output transfer functions for luminance space transforms, rather than defining the luminance space of an input directly Signed-off-by: Harry Wentland --- Documentation/gpu/rfc/hdr-wide-gamut.rst | 416 +++ Documentation/gpu/rfc/index.rst | 4 + 2 files changed, 420 insertions(+) create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst diff --git a/Documentation/gpu/rfc/hdr-wide-gamut.rst b/Documentation/gpu/rfc/hdr-wide-gamut.rst new file mode 100644 index ..132898668eac --- /dev/null +++ b/Documentation/gpu/rfc/hdr-wide-gamut.rst @@ -0,0 +1,416 @@ +== +HDR & Wide Color Gamut Support +== + +.. role:: wy-text-strike + +ToDo + + +* :wy-text-strike:`Reformat as RST kerneldoc` - done +* :wy-text-strike:`Don't use color_encoding for color_space definitions` - done +* :wy-text-strike:`Update SDR luminance description and reasoning` - done +* :wy-text-strike:`Clarify 3D LUT required for some color space transformations` - done +* :wy-text-strike:`Highlight need for named color space and EOTF definitions` - done +* :wy-text-strike:`Define transfer function API` - done +* :wy-text-strike:`Draft upstream plan` - done +* Reference to wayland and/or Chrome plans +* Sketch view of HW pipeline for couple of HW implementations + + +Upstream Plan += + +* Reach consensus on DRM/KMS API +* Implement support in amdgpu +* Implement IGT tests +* Add API support to Weston, ChromiumOS, or other canonical open-source project interested in HDR +* Merge user-space +* Merge kernel patches + + +Introduction + + +We are looking to enable HDR support for a couple of single-plane and +multi-plane scenarios. To do this effectively we recommend new interfaces +to drm_plane. Below I'll give a bit of background on HDR and why we +propose these interfaces. + + +Overview and background +=== + +Defining a pixel's luminance + + +The luminance space of pixels in a framebuffer/plane presented to the +display is not well defined in the DRM/KMS APIs. It is usually assumed to +be in a 2.2 or 2.4 gamma space and has no mapping to an absolute luminance +value; it is interpreted in relative terms. + +Luminance can be measured and described in absolute terms as candela +per meter squared, or cd/m2, or nits. Even though a pixel value can be +mapped to luminance in a linear fashion to do so without losing a lot of +detail requires 16-bpc color depth. The reason for this is that human +perception can distinguish roughly between a 0.5-1% luminance delta. A +linear representation is suboptimal, wasting precision in the highlights +and losing precision in the shadows. + +A gamma curve is a decent approximation to a human's perception of +luminance, but the PQ (perceptual quantizer) function [1] improves on +it. It also defines the luminance values in absolute terms, with the +highest value being 10,000 nits and the lowest 0.0005 nits. + +Using a content that's defined in PQ space we can approximate the real +world in a much better way. + +Here are some examples of real-life objects and their approximate +luminance values: + +.. flat-table:: + :header-rows: 1 + + * - Object + - Luminance in nits + + * - Fluorescent light + - 10,000 + + * - Highlights + - 1,000 - sunlight + + * - White Objects + - 250 - 1,000 + + * - Typical Objects + - 1 - 250 + + * - Shadows + - 0.01 - 1 + + * - Ultra Blacks + - 0 - 0.0005 + +Transfer functions +-- + +Traditionally we used the terms gamma and de-gamma to describe the +encoding of a pixel's luminance value and the operation to transfer from +a linear luminance space to the non-linear space used to encode the +pixels. Since some newer encodings don't use a gamma curve I suggest +we refer to non-linear encodings using the terms EOTF, and OETF[2], or +simply as transfer function in general. + +The EOTF (Electro-Optical Transfer Function) describes how to transfer +from an electrical signal to an optical signal. This was traditionally +done by the de-gamma function. + +The OETF (Opto Electronic Transfer Function) describes how to transfer +from an optical signal to an electronic signal. This was traditionally +done by the gamma function. + +More generally we can name the transfer function describing the transform +between scanout and blending space as the **input transfer function**, and +the transfer function describing the transform from blending space to the +output space as **output transfer function**. + + +Mastering Luminances
[RFC PATCH v2 0/6] A drm_plane API to support HDR planes
We are looking to enable HDR support for a couple of single-plane and multi-plane scenarios. To do this effectively we recommend new interfaces to drm_plane. The first patch gives a bit of background on HDR and why we propose these interfaces. v2: * Moved RFC from cover letter to kernel doc (Daniel Vetter) * Created new color space property instead of abusing color_encoding property (Ville) * Elaborated on need for named transfer functions * Expanded on reason for SDR luminance definition * Dropped 'color' from transfer function naming * Added output_transfer_function on crtc Bhawanpreet Lakha (3): drm/color: Add transfer functions for HDR/SDR on drm_plane drm/color: Add sdr boost property drm/color: Add color space plane property Harry Wentland (3): drm/doc: Color Management and HDR10 RFC drm/color: Add output transfer function to crtc drm/amd/display: reformat YCbCr-RGB conversion matrix Documentation/gpu/rfc/hdr-wide-gamut.rst | 416 ++ Documentation/gpu/rfc/index.rst | 4 + .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 +- drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 28 +- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 7 +- .../gpu/drm/arm/display/komeda/komeda_plane.c | 6 +- drivers/gpu/drm/arm/malidp_crtc.c | 7 +- drivers/gpu/drm/arm/malidp_planes.c | 6 +- drivers/gpu/drm/armada/armada_crtc.c | 5 +- drivers/gpu/drm/armada/armada_overlay.c | 6 +- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 7 +- drivers/gpu/drm/drm_atomic_uapi.c | 8 + drivers/gpu/drm/drm_color_mgmt.c | 177 +++- drivers/gpu/drm/i915/display/intel_color.c| 11 +- drivers/gpu/drm/i915/display/intel_color.h| 2 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- drivers/gpu/drm/i915/display/intel_sprite.c | 6 +- .../drm/i915/display/skl_universal_plane.c| 6 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c| 6 +- drivers/gpu/drm/nouveau/dispnv50/head.c | 13 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +- drivers/gpu/drm/omapdrm/omap_plane.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 7 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +- drivers/gpu/drm/stm/ltdc.c| 8 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 10 +- drivers/gpu/drm/tidss/tidss_crtc.c| 9 +- drivers/gpu/drm/tidss/tidss_plane.c | 10 +- drivers/gpu/drm/vc4/vc4_crtc.c| 16 +- include/drm/drm_color_mgmt.h | 49 ++- include/drm/drm_crtc.h| 20 + include/drm/drm_plane.h | 47 +- 35 files changed, 905 insertions(+), 60 deletions(-) create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst -- 2.31.1
Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote: > On Mon, 26 Apr 2021 13:38:49 -0400 > Harry Wentland wrote: > >> ## Introduction >> >> We are looking to enable HDR support for a couple of single-plane and >> multi-plane scenarios. To do this effectively we recommend new >> interfaces to drm_plane. Below I'll give a bit of background on HDR >> and why we propose these interfaces. >> >> >> ## Defining a pixel's luminance >> >> Currently the luminance space of pixels in a framebuffer/plane >> presented to the display is not well defined. It's usually assumed to >> be in a 2.2 or 2.4 gamma space and has no mapping to an absolute >> luminance value but is interpreted in relative terms. >> >> Luminance can be measured and described in absolute terms as candela >> per meter squared, or cd/m2, or nits. Even though a pixel value can >> be mapped to luminance in a linear fashion to do so without losing a >> lot of detail requires 16-bpc color depth. The reason for this is >> that human perception can distinguish roughly between a 0.5-1% >> luminance delta. A linear representation is suboptimal, wasting >> precision in the highlights and losing precision in the shadows. >> >> A gamma curve is a decent approximation to a human's perception of >> luminance, but the PQ (perceptual quantizer) function [1] improves on >> it. It also defines the luminance values in absolute terms, with the >> highest value being 10,000 nits and the lowest 0.0005 nits. >> >> Using a content that's defined in PQ space we can approximate the >> real world in a much better way. >> >> Here are some examples of real-life objects and their approximate >> luminance values: >> >> | Object| Luminance in nits | >> | - | - | >> | Sun | 1.6 million | >> | Fluorescent light | 10,000| >> | Highlights| 1,000 - sunlight | >> | White Objects | 250 - 1,000 | >> | Typical objects | 1 - 250 | >> | Shadows | 0.01 - 1 | >> | Ultra Blacks | 0 - 0.0005| >> >> >> ## Describing the luminance space >> >> **We propose a new drm_plane property to describe the Eletro-Optical >> Transfer Function (EOTF) with which its framebuffer was composed.** >> Examples of EOTF are: >> >> | EOTF | Description >>| >> | - >> |:- | >> | Gamma 2.2 | a simple 2.2 gamma >>| >> | sRGB | 2.4 gamma with small initial linear section >>| >> | PQ 2084 | SMPTE ST 2084; used for HDR video and allows for up to 10,000 >> nit support | >> | Linear| Linear relationship between pixel value and luminance value >>| >> > > The definitions agree with what I have learnt so far. However, with > these EOTF definitions, only PQ defines absolute luminance values > while the others do not. So this is not enough information to blend > planes together if they do not all use the same EOTF with the same > dynamic range. More below. > Good point. > >> >> ## Mastering Luminances >> >> Now we are able to use the PQ 2084 EOTF to define the luminance of >> pixels in absolute terms. Unfortunately we're again presented with >> physical limitations of the display technologies on the market today. >> Here are a few examples of luminance ranges of displays. >> >> | Display | Luminance range in nits | >> | | --- | >> | Typical PC display | 0.3 - 200 | >> | Excellent LCD HDTV | 0.3 - 400 | >> | HDR LCD w/ local dimming | 0.05 - 1,500| >> >> Since no display can currently show the full 0.0005 to 10,000 nits >> luminance range the display will need to tonemap the HDR content, i.e >> to fit the content within a display's capabilities. To assist with >> tonemapping HDR content is usually accompanied with a metadata that >> describes (among other things) the minimum and maximum mastering >> luminance, i.e. the maximum and minimum luminance of the display that >> was used to master the HDR content. >> >> The HDR metadata is currently defined on the drm_connector via the >> hdr_output_metadata blob property. >> >> It might be useful to define per-plane hdr metadata, as different >> planes might have been mastered differently. > > I don't think this would directly help with the dynamic range blending > problem. You still need to establish the mapping between the optical > values from two different EOTFs and dynamic ranges. Or can you know > which optical values match the mastering display maximum and minimum > luminances for not-PQ? > My understanding of this is probably best illustrated by this example: Assume HDR was mastered on a display with a maximum white level of 500 nits and played back on a display that
Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings
On 2021-04-30 8:53 p.m., Sebastian Wick wrote:
> On 2021-04-26 20:56, Harry Wentland wrote:
>> On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
>>> On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
From: Bhawanpreet Lakha
Add the following color encodings
- RGB versions for BT601, BT709, BT2020
- DCI-P3: Used for digital movies
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_color_mgmt.c | 4
include/drm/drm_color_mgmt.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c
b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6..a183ebae2941 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -469,6 +469,10 @@ static const char * const color_encoding_name[] = {
[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+ [DRM_COLOR_RGB_BT601] = "ITU-R BT.601 RGB",
+ [DRM_COLOR_RGB_BT709] = "ITU-R BT.709 RGB",
+ [DRM_COLOR_RGB_BT2020] = "ITU-R BT.2020 RGB",
+ [DRM_COLOR_P3] = "DCI-P3",
>>>
>>> These are a totally different thing than the YCbCr stuff.
>>> The YCbCr stuff just specifies the YCbCr<->RGB converison matrix,
>>> whereas these are I guess supposed to specify the primaries/whitepoint?
>>> But without specifying what we're converting *to* these mean absolutely
>>> nothing. Ie. I don't think they belong in this property.
>>>
>>
>> If this is the intention I don't see it documented.
>>
>> I might have overlooked something but do we have a way to explicitly
>> specify today what *to* format the YCbCr color encodings convert into?
>> Would that be a combination of the output color encoding specified via
>> colorspace_property and the color space encoded in the primaries and
>> whitepoint of the hdr_output_metadata?
>>
>> Fundamentally I don't see how the use of this property differs,
>> whether you translate from YCbCr or from RGB. In either case you're
>> converting from the defined input color space and pixel format to an
>> output color space and pixel format.
>>
>>> The previous proposals around this topic have suggested a new
>>> property to specify a conversion matrix either explicitly, or
>>> via a separate enum (which would specify both the src and dst
>>> colorspaces). I've always argued the enum approach is needed
>>> anyway since not all hardware has a programmable matrix for
>>> this. But a fully programmable matrix could be nice for tone
>>> mapping purposes/etc, so we may want to make sure both are
>>> possible.
>>>
>>> As for the transfer func, the proposals so far have mostly just
>>> been to expose a programmable degamma/gamma LUTs for each plane.
>>> But considering how poor the current gamma uapi is we've thrown
>>> around some ideas how to allow the kernel to properly expose the
>>> hw capabilities. This is one of those ideas:
>>> https://lists.freedesktop.org/archives/dri-devel/2019-April/212886.html I
>>> think that basic idea could be also be extended to allow fixed
>>> curves in case the hw doesn't have a fully programmable LUT. But
>>> dunno if that's relevant for your hw.
>>>
>>
>> The problem with exposing gamma, whether per-plane or per-crtc, is
>> that it is hard to define an API that works for all the HW out there.
>> The capabilities for different HW differ a lot, not just between
>> vendors but also between generations of a vendor's HW.
>
> Introducing another API if hardware is sufficiently different doesn't
> seem like the worst idea. At least it sounds a lot more tractable than
> teaching the kernel about all the different use cases, opinions and
> nuances that arise from color management.
>
> In the end generic user space must always be able to fall back to
> software so the worst case is that it won't be able to offload an
> operation if it doesn't know about a new API.
>
>> Another reason I'm proposing to define the color space (and gamma) of
>> a plane is to make this explicit. Up until the color space and gamma
>> of a plane or framebuffer are not well defined, which leads to drivers
>> assuming the color space and gamma of a buffer (for blending and other
>> purposes) and might lead to sub-optimal outcomes.
>
> Blending only is "correct" with linear light so that property of the
> color space is important. However, why does the kernel have to be
> involved here? As long as user space knows that for correct blending the
> data must represent linear light and knows when in the pipeline blending
> happens it can make sure that the data at that point in the pipeline
> contains linear light.
>
The only reason the kernel needs to be involved is to take full advantage
of the available HW without requiring KMS clients to be aware of
the difference in display HW.
Harry
> What other
[git pull] drm fixes for 5.13-rc2 (part two)
Hey, Looks like I wasn't the only one not fully switched on this week, the msm pull has a missing tag so I missed it, and i915 team were a bit late. In my defence I did have a day with the roof of my home office removed, so was sitting at my kids desk. Dave. drm-fixes-2021-05-15: drm fixes for 5.13-rc2 (part two) msm: - dsi regression fix - dma-buf pinning fix - displayport fixes - llc fix i915: - Fix active callback alignment annotations and subsequent crashes - Retract link training strategy to slow and wide, again - Avoid division by zero on gen2 - Use correct width reads for C0DRB3/C1DRB3 registers - Fix double free in pdp allocation failure path - Fix HDMI 2.1 PCON downstream caps check The following changes since commit 08f0cfbf739a5086995f0779bbcb607163128a9a: Merge tag 'amd-drm-fixes-5.13-2021-05-13' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-05-14 09:20:04 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-05-15 for you to fetch changes up to 5dce58de4be8a4c9f2af3beed3ee9813933a0583: Merge tag 'drm-msm-fixes-2021-05-09' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2021-05-15 06:52:15 +1000) drm fixes for 5.13-rc2 (part two) msm: - dsi regression fix - dma-buf pinning fix - displayport fixes - llc fix i915: - Fix active callback alignment annotations and subsequent crashes - Retract link training strategy to slow and wide, again - Avoid division by zero on gen2 - Use correct width reads for C0DRB3/C1DRB3 registers - Fix double free in pdp allocation failure path - Fix HDMI 2.1 PCON downstream caps check Ankit Nautiyal (1): drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON Dave Airlie (2): Merge tag 'drm-intel-fixes-2021-05-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-msm-fixes-2021-05-09' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Dmitry Baryshkov (2): drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code Jonathan Marek (2): drm/msm: fix LLC not being enabled for mmu500 targets drm/msm: fix minor version to indicate MSM_PARAM_SUSPENDS support Kai-Heng Feng (1): drm/i915/dp: Use slow and wide link training for everything Kuogee Hsieh (2): drm/msm/dp: check sink_count before update is_connected status drm/msm/dp: initialize audio_comp when audio starts Lv Yunlong (1): drm/i915/gt: Fix a double free in gen8_preallocate_top_level_pdp Rob Clark (1): drm/msm: Do not unpin/evict exported dma-buf's Stéphane Marchesin (1): drm/i915: Fix crash in auto_retire Tvrtko Ursulin (1): drm/i915/overlay: Fix active retire callback alignment Ville Syrjälä (2): drm/i915: Avoid div-by-zero on gen2 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again drivers/gpu/drm/i915/display/intel_dp.c | 61 +++-- drivers/gpu/drm/i915/display/intel_overlay.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c| 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 1 - drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c| 4 +- drivers/gpu/drm/i915/i915_active.c | 3 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 ++-- drivers/gpu/drm/msm/dp/dp_audio.c | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 26 +++ drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 ++ drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/msm/msm_gem.c | 16 ++- drivers/gpu/drm/msm/msm_gem.h | 4 +- 15 files changed, 59 insertions(+), 79 deletions(-)
Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes
On 2021-04-30 6:39 a.m., Shashank Sharma wrote: > Hello Pekka, > > On 30/04/21 15:13, Pekka Paalanen wrote: >> On Wed, 28 Apr 2021 13:24:27 +0530 >> Shashank Sharma wrote: >> >>> Assuming these details, A compositor will look for DRM color properties >>> like these: >>> >>> 1. Degamma plane property : To make buffers linear for Gamut mapping >>> >>> 2. Gamut mapping plane property: To gamut map SRGB buffer to BT2020 >>> colorspace >>> >>> 3. Color space conversion plane property: To convert from YCBCR->RGB >>> >>> 4. Tone mapping plane property: To tone map SDR buffer S2H and HDR buffer >>> H2H >>> >>> 5. Gamma plane/CRTC property: to re-apply the output ST2084 curve >>> >>> >> ... >> >>> * >>> * >>> * >>> * ┌─┐ ┌─┐ >>> ┌─┐ ┌┐ >>> * HDR 600 Nits│ │HDR 600 Nits │ │HDR600 >>> │ │HDR500 │ │ HDR500 >>> * ► │ Degamma ├►│ Color space >>> ├──►│ Tone mapping ├──►│ Gamma │ >>> * BT2020 │ OETF ST2084 │ BT2020 │ conversion │BT2020 >>> │ H2H │BT2020 │ ST2084 │ BT2020 >>> * YCBCR420 │ │ YCBCR420 │ YCBCR->RGB │RGB88 >>> │ 600->500 │RGB888 │ │ RGB888 >>> * Non Linear └─┘ Linear └─┘Linear >>> └─┘Linear └┘ ST2084 >>> */ >> Hi Shashank, >> >> I think you might have degamma and color model conversion reversed, or >> is that a new thing in the HDR specs? >> >> Usually the YCbCr/RGB conversion matrix applies to non-linear values >> AFAIU. > Ah, that was due to the Gamut mapping block. You are right, color format > conversion can happen on non-linear data (doesn't mean it can't happen on > linear), but in the sequential block above, there was gamut mapping (color > space conversion), which needs to be done on Linear space, and I was a bit > too lazy to create separate blocks, so I just re[placed the block titles :D. >> There is also confusion with OETF vs. EOTF. I got that initially wrong >> too. OETF is not just a name for inverse-EOTF but it is used in a >> different context. Though here it seems to be just a typo. >> OETF is inherent to a camera when it converts light into >> electrical signals. EOTF is inherent to a monitor when it converts >> electrical signals to light. Depending on what the electrical signals >> have been defined to be in each step of a broadcasting chain, you might >> need OETF or EOTF or their inverse or a different OETF or EOTF or their >> inverse. > > Yes, that was a typo. The intention was to call it inverse curve for HDR > encoded buffers. It's almost 4 years (and 2 companies) since I last did HDR, > so I am a bit rusty on the topic ;) . > > - Shashank > Thanks, Ville and Shashank. This is indeed helpful. I apologize for the late response but I needed to take some time to do more reading and internalize some of the HDR and CM concepts. I will send out a v2 of my patchset but realize that it is only a small step toward the right KMS interface for HDR and CM. Harry >> >> As we are talking about displays and likely assuming display-referred >> content (not scene-referred content), we probably have no use for OETF, >> but we could have several different EOTFs. >> >> >> Thanks, >> pq
[PATCH 1/1] drm: drm_legacy_addbufs_pci(): fix return without cleanup
The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free" leads
to the following static checker warning:
drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
warn: inconsistent returns '>struct_mutex'.
Locked on : 988
Unlocked on: 938,944,951,959,973,1005,1042,1060,1090
Fix the return without cleanup by removing the early return and taking
the original return path on allocation failure, including the intended
unlocks.
Signed-off-by: Joseph Kogut
---
drivers/gpu/drm/drm_bufs.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 94bc1f6049c9..ea3ca81be9dd 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -984,17 +984,18 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
while (entry->buf_count < count) {
dmah = kmalloc(sizeof(drm_dma_handle_t), GFP_KERNEL);
- if (!dmah)
- return -ENOMEM;
-
- dmah->size = total;
- dmah->vaddr = dma_alloc_coherent(dev->dev,
-dmah->size,
->busaddr,
-GFP_KERNEL);
- if (!dmah->vaddr) {
- kfree(dmah);
-
+ if (dmah) {
+ dmah->size = total;
+ dmah->vaddr = dma_alloc_coherent(dev->dev,
+dmah->size,
+>busaddr,
+GFP_KERNEL);
+ if (!dmah->vaddr) {
+ kfree(dmah);
+ dmah = NULL;
+ }
+ }
+ if (!dmah) {
/* Set count correctly so we free the proper amount. */
entry->buf_count = count;
entry->seg_count = count;
--
2.31.1
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 1:25 PM Maciej W. Rozycki wrote: > > Overall I think it does make sense to resize the text console at any > time, even if the visible console (VT) chosen is in the graphics mode, It might make sense, but only if we call the function to update the low-level data. Not calling it, and then starting to randomly use the (wrong) geometry, and just limiting it so that it's all within the buffer - THAT does not make sense. So I think your patch is fundamentally wrong. It basically says "let's use random stale incorrect data, but just make sure that the end result is still within the allocated buffer". My patch is at least conceptually sane. An alternative would be to just remove the "vcmode != KD_GRAPHICS" check entirely, and always call con_resize() to update the low-level data, but honestly, that seems very likelty to break something very fundamentally, since it's not how any of fbcon has ever been tested, Another alternative would be to just delay the resize to when vcmode is put back to text mode again. That sounds somewhat reasonable to me, but it's a pretty big thing. But no, your patch to just "knowingly use entirely wrong values, then add a limit check because we know the values are possibly garbage and not consistent with reality" is simply not acceptable. Linus
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Currently it is impossible to control upper limit of rows/columns values
> > based on amount of memory reserved for the graphical screen, for
> > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
> > already KD_GRAPHICS
>
> Honestly, the saner approach would seem to be to simply error out if
> vc_mode is KD_GRAPHICS.
>
> Doing VT_RESIZE while in KD_GRAPHICS mode seems _very_ questionable,
> and is clearly currently very buggy.
I haven't looked into it any further beyond tracking down (again, using
the LMO tree) the originating change as the other fix took precedence. It
came with:
commit 094e0a9cdbdf1e11a28dd756a6cbd750b6303d10
Author: Ralf Baechle
Date: Sun Jun 1 12:07:37 2003 +
Merge with Linux 2.5.51
along with framebuffer console support:
+inline int resize_screen(int currcons, int width, int height)
+{
+ /* Resizes the resolution of the display adapater */
+ int err = 0;
+
+ if (vcmode != KD_GRAPHICS && sw->con_resize)
+ err = sw->con_resize(vc_cons[currcons].d, width, height);
+ return err;
+}
+
A handler for fbcon was added shortly afterwards with:
commit bab384bdbe279efd7acc2146ef13b0b0395b2a42
Author: Ralf Baechle
Date: Tue Jun 3 17:04:10 2003 +
Merge with Linux 2.5.59.
however vgacon didn't have a handler for it until commit 28254d439b8c
("[PATCH] vga text console and stty cols/rows") two years later only.
Overall I think it does make sense to resize the text console at any
time, even if the visible console (VT) chosen is in the graphics mode, as
my understanding (and experience at least with vgacon) is that resizing
the console applies globally across all the VTs. So the intent of the
original change appears valid to me, and the choice not to reprogram the
visible console and only store the settings for a future use if it's in
the graphics mode correct.
Which means any bug triggered here needs to be fixed elsewhere rather
than by making the request fail.
NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO
rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with
it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is
kind enough to know how to fiddle with its clockchip. It works just fine.
Maciej
Re: [Intel-gfx] [RFC PATCH 4/5] drm/i915: Introduce 'set parallel submit' extension
On Wed, May 12, 2021 at 10:34:59AM +0200, Daniel Vetter wrote:
> On Tue, May 11, 2021 at 11:44:28AM -0700, Matthew Brost wrote:
> > On Tue, May 11, 2021 at 05:11:44PM +0200, Daniel Vetter wrote:
> > > On Thu, May 06, 2021 at 10:30:48AM -0700, Matthew Brost wrote:
> > > > i915_drm.h updates for 'set parallel submit' extension.
> > > >
> > > > Cc: Tvrtko Ursulin
> > > > Cc: Tony Ye
> > > > CC: Carl Zhang
> > > > Cc: Daniel Vetter
> > > > Cc: Jason Ekstrand
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > include/uapi/drm/i915_drm.h | 126
> > > > 1 file changed, 126 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 26d2e135aa31..0175b12b33b8 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -1712,6 +1712,7 @@ struct drm_i915_gem_context_param {
> > > > * Extensions:
> > > > * i915_context_engines_load_balance
> > > > (I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE)
> > > > * i915_context_engines_bond (I915_CONTEXT_ENGINES_EXT_BOND)
> > > > + * i915_context_engines_parallel_submit
> > > > (I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT)
> > >
> > > Hm just relalized, but I don't think this hyperlinsk correctly, and I'm
> > > also not sure this formats very well as a nice list. Using item lists
> > > should look pretty nice like we're doing for the various kms properties,
> > > e.g.
> > >
> > > FOO:
> > > Explain what FOO does
> > >
> > > BAR:
> > > Explain what BAR does. struct bar also automatically generates a link
> > >
> > > Please check with make htmldocs and polish this a bit (might need a small
> > > prep patch).
> > >
> >
> > I agree the doc should look nice. To get there I might need to chat with
> > you on
> > IRC as I'm new to this.
> >
> > > > */
> > > > #define I915_CONTEXT_PARAM_ENGINES 0xa
> > > >
> > > > @@ -1894,9 +1895,134 @@ struct i915_context_param_engines {
> > > > __u64 extensions; /* linked chain of extension blocks, 0
> > > > terminates */
> > > > #define I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE 0 /* see
> > > > i915_context_engines_load_balance */
> > > > #define I915_CONTEXT_ENGINES_EXT_BOND 1 /* see
> > > > i915_context_engines_bond */
> > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> > > > i915_context_engines_parallel_submit */
> > > > struct i915_engine_class_instance engines[0];
> > > > } __attribute__((packed));
> > > >
> > > > +/*
> > > > + * i915_context_engines_parallel_submit:
> > > > + *
> > > > + * Setup a gem context to allow multiple BBs to be submitted in a
> > > > single execbuf
> > > > + * IOCTL. Those BBs will then be scheduled to run on the GPU in
> > > > parallel.
> > > > + *
> > > > + * All hardware contexts in the engine set are configured for parallel
> > > > + * submission (i.e. once this gem context is configured for parallel
> > > > submission,
> > > > + * all the hardware contexts, regardless if a BB is available on each
> > > > individual
> > > > + * context, will be submitted to the GPU in parallel). A user can
> > > > submit BBs to
> > > > + * subset of the hardware contexts, in a single execbuf IOCTL, but it
> > > > is not
> > > > + * recommended as it may reserve physical engines with nothing to run
> > > > on them.
> > > > + * Highly recommended to configure the gem context with N hardware
> > > > contexts then
> > > > + * always submit N BBs in a single IOCTL.
> > > > + *
> > > > + * Their are two currently defined ways to control the placement of the
> > > > + * hardware contexts on physical engines: default behavior (no flags)
> > > > and
> > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the
> > > > in the
> > > > + * future as new hardware / use cases arise. Details of how to use this
> > > > + * interface below above the flags.
> > > > + *
> > > > + * Returns -EINVAL if hardware context placement configuration invalid
> > > > or if the
> > > > + * placement configuration isn't supported on the platform / submission
> > > > + * interface.
> > > > + * Returns -ENODEV if extension isn't supported on the platform /
> > > > submission
> > > > + * inteface.
> > > > + */
> > > > +struct i915_context_engines_parallel_submit {
> > > > + struct i915_user_extension base;
> > >
> > > Ok this is good, since it makes sure we can't possible use this in
> > > CTX_SETPARAM.
> > >
> >
> > Yep, this is at context creation time. Technically you still can call this
> > over
> > and over on the same gem context but Jason is taking that ability away I
> > believe. I've also told the media team to setup the context once and don't
> > touch
> > it again.
>
> Only if you base your context param on drm_i915_gem_context_param, which
> can be used both at create time with
> drm_i915_gem_context_create_ext_setparam and with the CTX_SETPARAM ioctl.
> But you don't, so this issue is fixed at the uapi
[PATCH v3 3/3] drm/ingenic: Add option to alloc cached GEM buffers
With the module parameter ingenic-drm.cached_gem_buffers, it is possible
to specify that we want GEM buffers backed by non-coherent memory.
This dramatically speeds up software rendering on Ingenic SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
blits).
Enable it on SoCs where it is actually faster than write-combine.
v3: The option is now selected per-SoC instead of being a module
parameter.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 56 ++-
drivers/gpu/drm/ingenic/ingenic-ipu.c | 18 ++--
2 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 09225b770bb8..5f64e8583eec 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +59,7 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool map_noncoherent;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -410,6 +413,8 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
crtc_state->mode_changed = true;
+ drm_atomic_helper_check_plane_damage(state, new_plane_state);
+
return 0;
}
@@ -544,8 +549,8 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
struct drm_atomic_state *state)
{
struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
- struct drm_plane_state *newstate = drm_atomic_get_new_plane_state(state,
-
plane);
+ struct drm_plane_state *newstate =
drm_atomic_get_new_plane_state(state, plane);
+ struct drm_plane_state *oldstate =
drm_atomic_get_old_plane_state(state, plane);
struct drm_crtc_state *crtc_state;
struct ingenic_dma_hwdesc *hwdesc;
unsigned int width, height, cpp, offset;
@@ -553,6 +558,8 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
u32 fourcc;
if (newstate && newstate->fb) {
+ drm_gem_cma_sync_data(>drm, oldstate, newstate);
+
crtc_state = newstate->crtc->state;
addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0);
@@ -742,6 +749,43 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
*crtc)
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_EOF_IRQ, 0);
}
+static int ingenic_drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int flags,
+unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+ struct ingenic_drm *priv = drm_device_get_priv(fb->dev);
+
+ if (!priv->soc_info->map_noncoherent)
+ return 0;
+
+ return drm_atomic_helper_dirtyfb(fb, file_priv, flags,
+color, clips, num_clips);
+}
+
+static const struct drm_framebuffer_funcs ingenic_drm_gem_fb_funcs = {
+ .destroy= drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+ .dirty = ingenic_drm_atomic_helper_dirtyfb,
+};
+
+static struct drm_gem_object *
+ingenic_drm_gem_create_object(struct drm_device *drm, size_t size)
+{
+ struct ingenic_drm *priv = drm_device_get_priv(drm);
+ struct drm_gem_cma_object *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ obj->map_noncoherent = priv->soc_info->map_noncoherent;
+
+ return >base;
+}
+
DEFINE_DRM_GEM_CMA_FOPS(ingenic_drm_fops);
static const struct drm_driver ingenic_drm_driver_data = {
@@ -754,6 +798,7 @@ static const struct drm_driver ingenic_drm_driver_data = {
.patchlevel = 0,
.fops = _drm_fops,
+ .gem_create_object = ingenic_drm_gem_create_object,
DRM_GEM_CMA_DRIVER_OPS,
.irq_handler= ingenic_drm_irq_handler,
@@ -961,6 +1006,8 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
return ret;
}
+ drm_plane_enable_fb_damage_clips(>f1);
+
drm_crtc_helper_add(>crtc, _drm_crtc_helper_funcs);
ret = drm_crtc_init_with_planes(drm, >crtc,
[PATCH v3 2/3] drm: Add and export function drm_gem_cma_sync_data
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: - Only sync data if using GEM objects backed by non-coherent memory.
- Use a drm_device pointer instead of device pointer in prototype
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_gem_cma_helper.c | 55
include/drm/drm_gem_cma_helper.h | 5 +++
2 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 81a31bcf7d68..9dbe766c3177 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -17,9 +17,14 @@
#include
#include
+#include
#include
#include
+#include
+#include
+#include
#include
+#include
#include
/**
@@ -589,3 +594,53 @@ int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
return drm_gem_prime_mmap(obj, vma);
}
EXPORT_SYMBOL(drm_gem_cma_prime_mmap);
+
+/**
+ * drm_gem_cma_sync_data - Sync GEM object to non-coherent backing memory
+ * @drm: DRM device
+ * @old_state: Old plane state
+ * @state: New plane state
+ *
+ * This function can be used by drivers that use damage clips and have
+ * CMA GEM objects backed by non-coherent memory. Calling this function
+ * in a plane's .atomic_update ensures that all the data in the backing
+ * memory have been written to RAM.
+ */
+void drm_gem_cma_sync_data(struct drm_device *drm,
+ struct drm_plane_state *old_state,
+ struct drm_plane_state *state)
+{
+ const struct drm_format_info *finfo = state->fb->format;
+ struct drm_atomic_helper_damage_iter iter;
+ const struct drm_gem_cma_object *cma_obj;
+ unsigned int offset, i;
+ struct drm_rect clip;
+ dma_addr_t daddr;
+
+ for (i = 0; i < finfo->num_planes; i++) {
+ cma_obj = drm_fb_cma_get_gem_obj(state->fb, i);
+
+ if (cma_obj->map_noncoherent)
+ break;
+ }
+
+ /* No non-coherent buffers - no need to sync anything. */
+ if (i == finfo->num_planes)
+ return;
+
+ drm_atomic_helper_damage_iter_init(, old_state, state);
+
+ drm_atomic_for_each_plane_damage(, ) {
+ for (i = 0; i < finfo->num_planes; i++) {
+ daddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
+
+ /* Ignore x1/x2 values, invalidate complete lines */
+ offset = clip.y1 * state->fb->pitches[i];
+
+ dma_sync_single_for_device(drm->dev, daddr + offset,
+ (clip.y2 - clip.y1) *
state->fb->pitches[i],
+ DMA_TO_DEVICE);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(drm_gem_cma_sync_data);
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index b597e00fd5f6..4ccc8c69e594 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -7,6 +7,7 @@
#include
struct drm_mode_create_dumb;
+struct drm_plane_state;
/**
* struct drm_gem_cma_object - GEM object backed by CMA memory allocations
@@ -187,4 +188,8 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*drm,
int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
+void drm_gem_cma_sync_data(struct drm_device *drm,
+ struct drm_plane_state *old_state,
+ struct drm_plane_state *state);
+
#endif /* __DRM_GEM_CMA_HELPER_H__ */
--
2.30.2
[PATCH v3 1/3] drm: Add support for GEM buffers backed by non-coherent memory
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a shadow buffer. This is true for
instance on some Ingenic SoCs, where even simple blits (e.g. memcpy)
are about three times faster using this method.
Add a 'map_noncoherent' flag to the drm_gem_cma_object structure, which
can be set by the drivers when they create the dumb buffer.
Since this really only applies to software rendering, disable this flag
as soon as the CMA objects are exported via PRIME.
v3: New patch. Now uses a simple 'map_noncoherent' flag to control how
the objects are mapped, and use the new dma_mmap_pages function.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_gem_cma_helper.c | 41 +---
include/drm/drm_gem_cma_helper.h | 7 -
2 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7942cf05cd93..81a31bcf7d68 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -115,8 +115,15 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
if (IS_ERR(cma_obj))
return cma_obj;
- cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
- GFP_KERNEL | __GFP_NOWARN);
+ if (cma_obj->map_noncoherent) {
+ cma_obj->vaddr = dma_alloc_noncoherent(drm->dev, size,
+ _obj->paddr,
+ DMA_TO_DEVICE,
+ GFP_KERNEL |
__GFP_NOWARN);
+ } else {
+ cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
+ GFP_KERNEL | __GFP_NOWARN);
+ }
if (!cma_obj->vaddr) {
drm_dbg(drm, "failed to allocate buffer with size %zu\n",
size);
@@ -499,8 +506,13 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
cma_obj = to_drm_gem_cma_obj(obj);
- ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
- cma_obj->paddr, vma->vm_end - vma->vm_start);
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ if (!cma_obj->map_noncoherent)
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+
+ ret = dma_mmap_pages(cma_obj->base.dev->dev,
+vma, vma->vm_end - vma->vm_start,
+virt_to_page(cma_obj->vaddr));
if (ret)
drm_gem_vm_close(vma);
@@ -556,3 +568,24 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*dev,
return obj;
}
EXPORT_SYMBOL(drm_gem_cma_prime_import_sg_table_vmap);
+
+/**
+ * drm_gem_cma_prime_mmap - PRIME mmap function for CMA GEM drivers
+ * @obj: GEM object
+ * @vma: Virtual address range
+ *
+ * Carbon copy of drm_gem_prime_mmap, but the 'map_noncoherent' flag is
+ * disabled to ensure that the exported buffers have the expected cache
+ * coherency.
+ */
+int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
+ struct vm_area_struct *vma)
+{
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
+
+ /* Use standard cache settings for PRIME-exported GEM buffers */
+ cma_obj->map_noncoherent = false;
+
+ return drm_gem_prime_mmap(obj, vma);
+}
+EXPORT_SYMBOL(drm_gem_cma_prime_mmap);
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 0a9711caa3e8..b597e00fd5f6 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -16,6 +16,7 @@ struct drm_mode_create_dumb;
* more than one entry but they are guaranteed to have contiguous
* DMA addresses.
* @vaddr: kernel virtual address of the backing memory
+ * @map_noncoherent: if true, the GEM object is backed by non-coherent memory
*/
struct drm_gem_cma_object {
struct drm_gem_object base;
@@ -24,6 +25,8 @@ struct drm_gem_cma_object {
/* For objects with DMA memory allocated by GEM CMA */
void *vaddr;
+
+ bool map_noncoherent;
};
#define to_drm_gem_cma_obj(gem_obj) \
@@ -119,7 +122,7 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma);
.prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
.prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, \
- .gem_prime_mmap = drm_gem_prime_mmap
+ .gem_prime_mmap = drm_gem_cma_prime_mmap
/**
* DRM_GEM_CMA_DRIVER_OPS - CMA GEM driver operations
@@ -181,5 +184,7 @@ struct drm_gem_object *
[PATCH v3 0/3] Add option to mmap GEM buffers cached
oRework of my previous patchset which added support for GEM buffers backed by non-coherent memory to the ingenic-drm driver. Having GEM buffers backed by non-coherent memory is interesting in the particular case where it is faster to render to a non-coherent buffer then sync the data cache, than to render to a write-combine buffer, and (by extension) much faster than using a shadow buffer. This is true for instance on some Ingenic SoCs, where even simple blits (e.g. memcpy) are about three times faster using this method. For the record, a previous patchset was accepted for 5.10 then had to be reverted, as it conflicted with some changes made to the DMA API. The first two patches add support for cached GEM buffers in the DRM core, the third patch adds support for this functionality in the ingenic-drm driver for the JZ4770 SoC. Cheers, -Paul Paul Cercueil (3): drm: Add support for GEM buffers backed by non-coherent memory drm: Add and export function drm_gem_cma_sync_data drm/ingenic: Add option to alloc cached GEM buffers drivers/gpu/drm/drm_gem_cma_helper.c | 96 ++- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 56 - drivers/gpu/drm/ingenic/ingenic-ipu.c | 18 - include/drm/drm_gem_cma_helper.h | 12 ++- 4 files changed, 171 insertions(+), 11 deletions(-) -- 2.30.2
[resend][pull] drm/msm: drm-msm-fixes-2021-05-09 for v5.13-rc2
Hi Dave & Daniel, First round of fixes for v5.13 The following changes since commit a29c8c0241654d5f3165d52e9307e4feff955621: drm/msm/disp/dpu1: fix display underruns during modeset. (2021-04-09 12:02:35 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2021-05-09 for you to fetch changes up to f2f46b878777e0d3f885c7ddad48f477b4dea247: drm/msm/dp: initialize audio_comp when audio starts (2021-05-06 16:26:57 -0700) Dmitry Baryshkov (2): drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code Jonathan Marek (2): drm/msm: fix LLC not being enabled for mmu500 targets drm/msm: fix minor version to indicate MSM_PARAM_SUSPENDS support Kuogee Hsieh (2): drm/msm/dp: check sink_count before update is_connected status drm/msm/dp: initialize audio_comp when audio starts Rob Clark (1): drm/msm: Do not unpin/evict exported dma-buf's drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 + drivers/gpu/drm/msm/dp/dp_audio.c | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 26 - drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/msm/msm_gem.c | 16 ++- drivers/gpu/drm/msm/msm_gem.h | 4 ++-- 9 files changed, 47 insertions(+), 18 deletions(-)
Re: [pull] drm/msm: drm-msm-fixes-2021-05-09 for v5.13-rc2
On Sun, May 9, 2021 at 4:21 PM Rob Clark wrote: > > Hi Dave & Daniel, > > First round of fixes for v5.13 > > The following changes since commit a29c8c0241654d5f3165d52e9307e4feff955621: > > drm/msm/disp/dpu1: fix display underruns during modeset. (2021-04-09 > 12:02:35 -0700) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/drm/msm.git this should have been: https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2021-05-09 BR, -R > > for you to fetch changes up to f2f46b878777e0d3f885c7ddad48f477b4dea247: > > drm/msm/dp: initialize audio_comp when audio starts (2021-05-06 > 16:26:57 -0700) > > > Dmitry Baryshkov (2): > drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access > drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code > > Jonathan Marek (2): > drm/msm: fix LLC not being enabled for mmu500 targets > drm/msm: fix minor version to indicate MSM_PARAM_SUSPENDS support > > Kuogee Hsieh (2): > drm/msm/dp: check sink_count before update is_connected status > drm/msm/dp: initialize audio_comp when audio starts > > Rob Clark (1): > drm/msm: Do not unpin/evict exported dma-buf's > > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 + > drivers/gpu/drm/msm/dp/dp_audio.c | 1 + > drivers/gpu/drm/msm/dp/dp_display.c | 26 > - > drivers/gpu/drm/msm/dp/dp_display.h | 1 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- > drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 > drivers/gpu/drm/msm/msm_drv.c | 2 +- > drivers/gpu/drm/msm/msm_gem.c | 16 ++- > drivers/gpu/drm/msm/msm_gem.h | 4 ++-- > 9 files changed, 47 insertions(+), 18 deletions(-)
Re: [PATCH 19/27] drm/i915/gem: Use the proto-context to handle create parameters
On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > This means that the proto-context needs to grow support for engine
> > configuration information as well as setparam logic. Fortunately, we'll
> > be deleting a lot of setparam logic on the primary context shortly so it
> > will hopefully balance out.
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 546 +-
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 58 ++
> > 2 files changed, 587 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 6dd50d669c5b9..aa4edfbf7ed48 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -193,8 +193,15 @@ static int validate_priority(struct drm_i915_private
> > *i915,
> >
> > static void proto_context_close(struct i915_gem_proto_context *pc)
> > {
> > + int i;
> > +
> > if (pc->vm)
> > i915_vm_put(pc->vm);
> > + if (pc->user_engines) {
> > + for (i = 0; i < pc->num_user_engines; i++)
> > + kfree(pc->user_engines[i].siblings);
> > + kfree(pc->user_engines);
>
> free_engines(>user_engines);
>
> Maybe even stuff that if check into free_engines. Except I realized this
> is proto engines here now :-(
>
> > + }
> > kfree(pc);
> > }
> >
> > @@ -248,6 +255,9 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > if (!pc)
> > return ERR_PTR(-ENOMEM);
> >
> > + pc->num_user_engines = -1;
> > + pc->user_engines = NULL;
> > +
> > if (HAS_FULL_PPGTT(i915)) {
> > struct i915_ppgtt *ppgtt;
> >
> > @@ -282,6 +292,439 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > return err;
> > }
> >
> > +static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
> > + struct i915_gem_proto_context *pc,
> > + const struct drm_i915_gem_context_param *args)
> > +{
> > + struct i915_address_space *vm;
> > +
> > + if (args->size)
> > + return -EINVAL;
> > +
> > + if (!pc->vm)
> > + return -ENODEV;
> > +
> > + if (upper_32_bits(args->value))
> > + return -ENOENT;
> > +
> > + rcu_read_lock();
> > + vm = xa_load(>vm_xa, args->value);
> > + if (vm && !kref_get_unless_zero(>ref))
> > + vm = NULL;
> > + rcu_read_unlock();
>
> vm lookup helpers would be nice I guess, but perhaps something that
> vm_bind patches should do.
I can add those. I just don't know where to put it. We don't have an
i915_gem_vm.h. Suggestions?
>
> > + if (!vm)
> > + return -ENOENT;
> > +
> > + i915_vm_put(pc->vm);
>
> Ah I guess I've found why you went with "pc->vm is always set". *shrug*
>
> > + pc->vm = vm;
> > +
> > + return 0;
> > +}
> > +
> > +struct set_proto_ctx_engines {
> > + struct drm_i915_private *i915;
> > + unsigned num_engines;
> > + struct i915_gem_proto_engine *engines;
> > +};
> > +
> > +static int
> > +set_proto_ctx_engines_balance(struct i915_user_extension __user *base,
> > + void *data)
> > +{
> > + struct i915_context_engines_load_balance __user *ext =
> > + container_of_user(base, typeof(*ext), base);
> > + const struct set_proto_ctx_engines *set = data;
> > + struct drm_i915_private *i915 = set->i915;
> > + struct intel_engine_cs **siblings;
> > + u16 num_siblings, idx;
> > + unsigned int n;
> > + int err;
> > +
> > + if (!HAS_EXECLISTS(i915))
> > + return -ENODEV;
> > +
> > + if (intel_uc_uses_guc_submission(>gt.uc))
> > + return -ENODEV; /* not implement yet */
> > +
> > + if (get_user(idx, >engine_index))
> > + return -EFAULT;
> > +
> > + if (idx >= set->num_engines) {
> > + drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
> > + idx, set->num_engines);
> > + return -EINVAL;
> > + }
> > +
> > + idx = array_index_nospec(idx, set->num_engines);
> > + if (set->engines[idx].type != I915_GEM_ENGINE_TYPE_INVALID) {
> > + drm_dbg(>drm,
> > + "Invalid placement[%d], already occupied\n", idx);
> > + return -EEXIST;
> > + }
> > +
> > + if (get_user(num_siblings, >num_siblings))
> > + return -EFAULT;
> > +
> > + err = check_user_mbz(>flags);
> > + if (err)
> > + return err;
> > +
> > + err = check_user_mbz(>mbz64);
> > + if (err)
> > + return err;
> > +
> > + if (num_siblings == 0)
> > + return 0;
>
> You deleted the on-stack siblings micro-optimization.
>
> I'm shocked.
Yup.
Re: [PATCH -next] drm/vmwgfx: Fix return value check in vmw_setup_pci_resources()
On 5/14/21 4:28 AM, Qiheng Lin wrote: In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. After that, the error code -ENOMEM should be returned. Reported-by: Hulk Robot Signed-off-by: Qiheng Lin Looks good. Thank you. I'll push it with some other fixes via drm-misc-next. z
Re: [PATCH][V2][next] drm/vmwgfx: Fix memory allocation check and a leak of object fifo
On 5/14/21 10:49 AM, Colin King wrote:
From: Colin Ian King
The allocation of fifo is lacking an allocation failure check, so
fix this by adding one.
In the case where fifo->static_buffer fails to be allocated the
error return path neglects to kfree the fifo object. Fix this by
adding in the missing kfree.
Kudos to Dan Carpenter for spotting the missing kzalloc failure
check.
Addresses-Coverity: ("Resource leak")
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Colin Ian King
---
V2: Add missing allocation failure check
Update $SUBJECT to reflect this extra change
Looks good. Thanks. I'll push it through drm-misc-next.
z
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 10:37 AM Linus Torvalds
wrote:
>
> IOW, something like this would seem fairly simple and straightforward:
Proper patch in case syzbot can test this..
Linus
From b33ca195cecea478768de353b3ae976c07a65615 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Fri, 14 May 2021 11:06:12 -0700
Subject: [PATCH] vt: don't allow text-mode resizing when in KD_GRAPHICS mode
The VT layer itself just keeps track of the underlying text contents
just fine, but if the underlying hardware driver has a con_resize()
function, we can't just ignore it when in KD_GRAPHICS mode.
So just refuse to do a text mode resize if we're not in text mode.
Reported-by: Tetsuo Handa
Reported-by: syzbot
Signed-off-by: Linus Torvalds
---
drivers/tty/vt/vt.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 01645e87b3d5..f24e627b7402 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1171,8 +1171,13 @@ static inline int resize_screen(struct vc_data *vc, int width, int height,
/* Resizes the resolution of the display adapater */
int err = 0;
- if (vc->vc_mode != KD_GRAPHICS && vc->vc_sw->con_resize)
+ if (vc->vc_sw->con_resize) {
+ // If we have a resize function but are in KD_GRAPHICS mode,
+ // we can't actually do a resize and need to error out.
+ if (vc->vc_mode == KD_GRAPHICS)
+ return -EINVAL;
err = vc->vc_sw->con_resize(vc, width, height, user);
+ }
return err;
}
--
2.31.1.365.ga2a05a39c5
Re: [Intel-gfx] [PATCH 17/27] drm/i915/gem: Rework error handling in default_engines
On Tue, May 4, 2021 at 11:17 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:38AM -0500, Jason Ekstrand wrote:
> > Since free_engines works for partially constructed engine sets, we can
> > use the usual goto pattern.
> >
> > Signed-off-by: Jason Ekstrand
>
> I guess subsequent patches apply the same for the set_engines command and
> __free_engines disappears? Otherwise feels a bit silly.
Working towards that.
> Anyway looks correct.
>
> Reviewed-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 10bd1b6dd1774..ce729e640bbf7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -420,7 +420,7 @@ static struct i915_gem_engines *default_engines(struct
> > i915_gem_context *ctx)
> > {
> > const struct intel_gt *gt = >i915->gt;
> > struct intel_engine_cs *engine;
> > - struct i915_gem_engines *e;
> > + struct i915_gem_engines *e, *err;
> > enum intel_engine_id id;
> >
> > e = alloc_engines(I915_NUM_ENGINES);
> > @@ -438,18 +438,21 @@ static struct i915_gem_engines
> > *default_engines(struct i915_gem_context *ctx)
> >
> > ce = intel_context_create(engine);
> > if (IS_ERR(ce)) {
> > - __free_engines(e, e->num_engines + 1);
> > - return ERR_CAST(ce);
> > + err = ERR_CAST(ce);
> > + goto free_engines;
> > }
> >
> > intel_context_set_gem(ce, ctx);
> >
> > e->engines[engine->legacy_idx] = ce;
> > - e->num_engines = max(e->num_engines, engine->legacy_idx);
> > + e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
> > }
> > - e->num_engines++;
> >
> > return e;
> > +
> > +free_engines:
> > + free_engines(e);
> > + return err;
> > }
> >
> > void i915_gem_context_release(struct kref *ref)
> > --
> > 2.31.1
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: [PATCH 10/27] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT
On Tue, May 4, 2021 at 3:56 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote:
> > Even though FENCE_SUBMIT is only documented to wait until the request in
> > the in-fence starts instead of waiting until it completes, it has a bit
> > more magic than that. If FENCE_SUBMIT is used to submit something to a
> > balanced engine, we would wait to assign engines until the primary
> > request was ready to start and then attempt to assign it to a different
> > engine than the primary. There is an IGT test which exercises this by
> > submitting a primary batch to a specific VCS and then using FENCE_SUBMIT
> > to submit a secondary which can run on any VCS and have i915 figure out
> > which VCS to run it on such that they can run in parallel.
> >
> > However, this functionality has never been used in the real world. The
> > media driver (the only user of FENCE_SUBMIT) always picks exactly two
> > physical engines to bond and never asks us to pick which to use.
>
> Maybe reference the specific igt you're break (and removing in the igt
> series to match this) here. Just for the record and all that.
Done.
> -Daniel
>
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h| 7 ---
> > .../drm/i915/gt/intel_execlists_submission.c| 17 -
> > 3 files changed, 1 insertion(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index d640bba6ad9ab..efb2fa3522a42 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -3474,7 +3474,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > if (args->flags & I915_EXEC_FENCE_SUBMIT)
> > err = i915_request_await_execution(eb.request,
> > in_fence,
> > -
> > eb.engine->bond_execute);
> > +NULL);
> > else
> > err = i915_request_await_dma_fence(eb.request,
> > in_fence);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 883bafc449024..68cfe5080325c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -446,13 +446,6 @@ struct intel_engine_cs {
> >*/
> > void(*submit_request)(struct i915_request *rq);
> >
> > - /*
> > - * Called on signaling of a SUBMIT_FENCE, passing along the signaling
> > - * request down to the bonded pairs.
> > - */
> > - void(*bond_execute)(struct i915_request *rq,
> > - struct dma_fence *signal);
> > -
> > /*
> >* Call when the priority on a request has changed and it and its
> >* dependencies may need rescheduling. Note the request itself may
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 14378b28169b7..635d6d2494d26 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3547,22 +3547,6 @@ static void virtual_submit_request(struct
> > i915_request *rq)
> > spin_unlock_irqrestore(>base.active.lock, flags);
> > }
> >
> > -static void
> > -virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
> > -{
> > - intel_engine_mask_t allowed, exec;
> > -
> > - allowed = ~to_request(signal)->engine->mask;
> > -
> > - /* Restrict the bonded request to run on only the available engines */
> > - exec = READ_ONCE(rq->execution_mask);
> > - while (!try_cmpxchg(>execution_mask, , exec & allowed))
> > - ;
> > -
> > - /* Prevent the master from being re-run on the bonded engines */
> > - to_request(signal)->execution_mask &= ~allowed;
> > -}
> > -
> > struct intel_context *
> > intel_execlists_create_virtual(struct intel_engine_cs **siblings,
> > unsigned int count)
> > @@ -3616,7 +3600,6 @@ intel_execlists_create_virtual(struct intel_engine_cs
> > **siblings,
> >
> > ve->base.schedule = i915_schedule;
> > ve->base.submit_request = virtual_submit_request;
> > - ve->base.bond_execute = virtual_bond_execute;
> >
> > INIT_LIST_HEAD(virtual_queue(ve));
> > ve->base.execlists.queue_priority_hint = INT_MIN;
> > --
> > 2.31.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH v6 6/9] drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 781c7cd98d75..bf8e4ed56847 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -449,11 +449,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct
intel_connector *connecto
int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
u8 pn, pn_min, pn_max;
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, ) ==
1) {
- pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
- max_backlight = (1 << pn) - 1;
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, ) !=
1) {
+ drm_dbg_kms(>drm, "Failed to read pwmgen bit count
cap\n");
+ return 0;
}
+ pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+ max_backlight = (1 << pn) - 1;
+
/* Find desired value of (F x P)
* Note that, if F x P is out of supported range, the maximum value or
* minimum value will applied automatically. So no need to check that.
--
2.31.1
[PATCH v6 5/9] drm/i915/dpcd_bl: Move VESA backlight enabling code closer together
No functional changes, just move set_vesa_backlight_enable() closer to it's
only caller: intel_dp_aux_vesa_enable_backlight().
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 54 +--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 1d31c33f4867..781c7cd98d75 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -270,33 +270,6 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector
*connector, enum pipe pi
}
/* VESA backlight callbacks */
-static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
-{
- struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 reg_val = 0;
-
- /* Early return when display use other mechanism to enable backlight. */
- if (!connector->panel.backlight.edp.vesa.aux_enable)
- return;
-
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
- drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_DISPLAY_CONTROL_REGISTER);
- return;
- }
- if (enable)
- reg_val |= DP_EDP_BACKLIGHT_ENABLE;
- else
- reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
-
- if (drm_dp_dpcd_writeb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- reg_val) != 1) {
- drm_dbg_kms(>drm, "Failed to %s aux backlight\n",
- enabledisable(enable));
- }
-}
-
static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct intel_connector
*connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -378,6 +351,33 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
}
}
+static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 reg_val = 0;
+
+ /* Early return when display use other mechanism to enable backlight. */
+ if (!connector->panel.backlight.edp.vesa.aux_enable)
+ return;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
+ drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
+ DP_EDP_DISPLAY_CONTROL_REGISTER);
+ return;
+ }
+ if (enable)
+ reg_val |= DP_EDP_BACKLIGHT_ENABLE;
+ else
+ reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
+
+ if (drm_dp_dpcd_writeb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ reg_val) != 1) {
+ drm_dbg_kms(>drm, "Failed to %s aux backlight\n",
+ enabledisable(enable));
+ }
+}
+
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state, u32 level)
--
2.31.1
[PATCH v6 9/9] drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.
Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 28
drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 ++--
drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +-
drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
4 files changed, 186 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c46d0374b6e6..80ad2d6b7e4b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1648,15 +1649,30 @@ nv50_sor_update(struct nouveau_encoder *nv_encoder, u8
head,
core->func->sor->ctrl(core, nv_encoder->or, nv_encoder->ctrl, asyh);
}
+/* TODO: Should we extend this to PWM-only backlights?
+ * As well, should we add a DRM helper for waiting for the backlight to
acknowledge
+ * the panel backlight has been shut off? Intel doesn't seem to do this, and
uses a
+ * fixed time delay from the vbios…
+ */
static void
nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state
*state)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
+ struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(state, nv_encoder);
+ struct nouveau_backlight *backlight = nv_connector->backlight;
struct drm_dp_aux *aux = _connector->aux;
+ int ret;
u8 pwr;
+ if (backlight && backlight->uses_dpcd) {
+ ret = drm_edp_backlight_disable(aux, >edp_info);
+ if (ret < 0)
+ NV_ERROR(drm, "Failed to disable backlight on
[CONNECTOR:%d:%s]: %d\n",
+nv_connector->base.base.id,
nv_connector->base.name, ret);
+ }
+
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
@@ -1695,6 +1711,9 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder,
struct drm_atomic_state *sta
struct drm_device *dev = encoder->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector;
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ struct nouveau_backlight *backlight;
+#endif
struct nvbios *bios = >vbios;
bool hda = false;
u8 proto = NV507D_SOR_SET_CONTROL_PROTOCOL_CUSTOM;
@@ -1769,6 +1788,14 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder,
struct drm_atomic_state *sta
proto = NV887D_SOR_SET_CONTROL_PROTOCOL_DP_B;
nv50_audio_enable(encoder, nv_crtc, nv_connector, state, mode);
+
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ backlight = nv_connector->backlight;
+ if (backlight && backlight->uses_dpcd)
+ drm_edp_backlight_enable(_connector->aux,
>edp_info,
+
(u16)backlight->dev->props.brightness);
+#endif
+
break;
default:
BUG();
@@ -2294,6 +2321,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
nv50_crc_atomic_start_reporting(state);
if (!flushed)
nv50_crc_atomic_release_notifier_contexts(state);
+
drm_atomic_helper_commit_hw_done(state);
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_helper_commit_cleanup_done(state);
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 72f35a2babcb..1cbd71abc80a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -42,11 +42,6 @@
static struct ida bl_ida;
#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
-struct nouveau_backlight {
- struct backlight_device *dev;
- int id;
-};
-
static bool
[PATCH v6 4/9] drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every driver from having to check everything against the eDP DPCD using DP
macros, which makes the code slightly easier to read (especially since the
names of some of the eDP capabilities don't exactly match up with what we
actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT
for instance).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_display_types.h| 2 ++
.../drm/i915/display/intel_dp_aux_backlight.c | 29 ---
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7054a37363fb..d4a57bce71b1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -312,6 +312,8 @@ struct intel_panel {
struct {
u8 pwmgen_bit_count;
u8 pwm_freq_pre_divider;
+ bool lsb_reg_used;
+ bool aux_enable;
} vesa;
struct {
bool sdr_uses_aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 1ab82933afb5..1d31c33f4867 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -270,13 +270,14 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector
*connector, enum pipe pi
}
/* VESA backlight callbacks */
-static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
- if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+ if (!connector->panel.backlight.edp.vesa.aux_enable)
return;
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
@@ -339,9 +340,11 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
}
- level = read_val[0];
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
+
+ if (connector->panel.backlight.edp.vesa.lsb_reg_used)
level = (read_val[0] << 8 | read_val[1]);
+ else
+ level = read_val[0];
return level;
}
@@ -359,13 +362,14 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
- vals[0] = level;
-
/* Write the MSB and/or LSB */
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
+ if (connector->panel.backlight.edp.vesa.lsb_reg_used) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
+ } else {
+ vals[0] = level;
}
+
if (drm_dp_dpcd_write(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals,
sizeof(vals)) != sizeof(vals)) {
drm_dbg_kms(>drm,
@@ -419,14 +423,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
intel_dp_aux_vesa_set_backlight(conn_state, level);
- set_vesa_backlight_enable(intel_dp, true);
+ set_vesa_backlight_enable(connector, true);
}
static void intel_dp_aux_vesa_disable_backlight(const struct
drm_connector_state *old_conn_state,
u32 level)
{
-
set_vesa_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
- false);
+
set_vesa_backlight_enable(to_intel_connector(old_conn_state->connector), false);
}
/*
@@ -524,8 +527,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct
intel_connector *connecto
static int intel_dp_aux_vesa_setup_backlight(struct intel_connector *connector,
enum pipe pipe)
{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_panel *panel = >panel;
+ if (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP)
+ panel->backlight.edp.vesa.aux_enable
[PATCH v6 8/9] drm/dp: Extract i915's eDP backlight code into DRM helpers
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bits such as setting the brightness level over AUX, probing the
backlight's TCON, enabling/disabling the backlight over AUX if supported,
etc. Any PWM-related portions of backlight control are explicitly left up
to the driver, as these will vary from platform to platform.
The only exception to this is the calculation of the PWM frequency
pre-divider value. This is because the only platform-specific information
required for this is the PWM frequency of the panel, which the driver is
expected to provide if available. The actual algorithm for calculating this
value is standard and is defined in the eDP specification from VESA.
Note that these helpers do not yet implement the full range of features
the VESA backlight interface provides, and only provide the following
functionality (all of which was already present in i915's DPCD backlight
support):
* Basic control of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight
v3:
* Split out changes to i915's backlight code to separate patches to make it
easier to review
v4:
* Style/spelling changes from Thomas Zimmermann
v5:
* Start using new drm_dbg_*() functions
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/drm_dp_helper.c | 347 ++
.../drm/i915/display/intel_display_types.h| 5 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 285 ++
include/drm/drm_dp_helper.h | 48 +++
4 files changed, 427 insertions(+), 258 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 55b53df6ce34..24bbc710c825 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3115,3 +3115,350 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux
*aux, u8 color_spc)
return 0;
}
EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
+
+/**
+ * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel via
AUX
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The brightness level to set
+ *
+ * Sets the brightness level of an eDP panel's backlight. Note that the
panel's backlight must
+ * already have been enabled by the driver by calling
drm_edp_backlight_enable().
+ *
+ * Returns: %0 on success, negative error code on failure
+ */
+int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+ u16 level)
+{
+ int ret;
+ u8 buf[2] = { 0 };
+
+ if (bl->lsb_reg_used) {
+ buf[0] = (level & 0xff00) >> 8;
+ buf[1] = (level & 0x00ff);
+ } else {
+ buf[0] = level;
+ }
+
+ ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
sizeof(buf));
+ if (ret != sizeof(buf)) {
+ drm_err(aux->drm_dev,
+ "%s: Failed to write aux backlight level: %d\n",
+ aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_edp_backlight_set_level);
+
+static int
+drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+bool enable)
+{
+ int ret;
+ u8 buf;
+
+ /* The panel uses something other then DPCD for enabling its backlight
*/
+ if (!bl->aux_enable)
+ return 0;
+
+ ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
+ if (ret != 1) {
+ drm_err(aux->drm_dev, "%s: Failed to read eDP display control
register: %d\n",
+ aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+ if (enable)
+ buf |= DP_EDP_BACKLIGHT_ENABLE;
+ else
+ buf &= ~DP_EDP_BACKLIGHT_ENABLE;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
+ if (ret != 1) {
+ drm_err(aux->drm_dev, "%s: Failed to write eDP display control
register: %d\n",
+ aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The initial backlight level to set via AUX, if there is one
+ *
+ * This function handles enabling DPCD backlight controls on a panel over
DPCD, while additionally
+ * restoring any important backlight state such as the
[PATCH v6 7/9] drm/i915/dpcd_bl: Print return codes for VESA backlight failures
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 101 +-
1 file changed, 52 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index bf8e4ed56847..95f2df631052 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -274,14 +274,12 @@ static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct
intel_connector *connec
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 mode_reg;
- if (drm_dp_dpcd_readb(_dp->aux,
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
- _reg) != 1) {
- drm_dbg_kms(>drm,
- "Failed to read the DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+ ret = drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _reg);
+ if (ret != 1) {
+ drm_dbg_kms(>drm, "Failed to read backlight mode: %d\n",
ret);
return false;
}
@@ -297,6 +295,7 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 read_val[2] = { 0x0 };
u16 level = 0;
@@ -307,10 +306,10 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
- if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val,
-sizeof(read_val)) != sizeof(read_val)) {
- drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
+ ret = drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val,
+ sizeof(read_val));
+ if (ret != sizeof(read_val)) {
+ drm_dbg_kms(>drm, "Failed to read brightness level:
%d\n", ret);
return 0;
}
@@ -333,6 +332,7 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 vals[2] = { 0x0 };
/* Write the MSB and/or LSB */
@@ -343,10 +343,10 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
vals[0] = level;
}
- if (drm_dp_dpcd_write(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals,
- sizeof(vals)) != sizeof(vals)) {
- drm_dbg_kms(>drm,
- "Failed to write aux backlight level\n");
+ ret = drm_dp_dpcd_write(_dp->aux,
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, vals,
+ sizeof(vals));
+ if (ret != sizeof(vals)) {
+ drm_dbg_kms(>drm, "Failed to write aux backlight level:
%d\n", ret);
return;
}
}
@@ -355,26 +355,28 @@ static void set_vesa_backlight_enable(struct
intel_connector *connector, bool en
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
if (!connector->panel.backlight.edp.vesa.aux_enable)
return;
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
- drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_DISPLAY_CONTROL_REGISTER);
+ ret = drm_dp_dpcd_readb(_dp->aux,
DP_EDP_DISPLAY_CONTROL_REGISTER, _val);
+ if (ret != 1) {
+ drm_dbg_kms(>drm, "Failed to read eDP display control
register: %d\n", ret);
return;
}
+
if (enable)
reg_val |= DP_EDP_BACKLIGHT_ENABLE;
else
reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
- if (drm_dp_dpcd_writeb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- reg_val) != 1) {
- drm_dbg_kms(>drm, "Failed to %s aux backlight\n",
-
[PATCH v6 3/9] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
v4:
* Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 1dbe38282ebe..1ab82933afb5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -382,7 +382,7 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_panel *panel = >panel;
- u8 dpcd_buf, new_dpcd_buf, edp_backlight_mode;
+ u8 dpcd_buf, new_dpcd_buf;
u8 pwmgen_bit_count = panel->backlight.edp.vesa.pwmgen_bit_count;
if (drm_dp_dpcd_readb(_dp->aux,
@@ -393,12 +393,8 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
new_dpcd_buf = dpcd_buf;
- edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- switch (edp_backlight_mode) {
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
+ if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
@@ -406,13 +402,6 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
pwmgen_bit_count) != 1)
drm_dbg_kms(>drm,
"Failed to write aux pwmgen bit count\n");
-
- break;
-
- /* Do nothing when it is already DPCD mode */
- case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
- default:
- break;
}
if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
--
2.31.1
[PATCH v6 1/9] drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculations
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
this value in intel_panel.backlight, and re-writing it as-needed.
Changes since v1:
* Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_dp_aux_backlight.c | 65 ++-
2 files changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9c0adfc60c6f..7054a37363fb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -311,6 +311,7 @@ struct intel_panel {
union {
struct {
u8 pwmgen_bit_count;
+ u8 pwm_freq_pre_divider;
} vesa;
struct {
bool sdr_uses_aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 8e9ac9ba1d38..68bfe50ada59 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -373,50 +373,6 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
}
}
-/*
- * Set PWM Frequency divider to match desired frequency in vbt.
- * The PWM Frequency is calculated as 27Mhz / (F x P).
- * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
- * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
- * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
- * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
- */
-static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
-{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct intel_dp *intel_dp = intel_attached_dp(connector);
- const u8 pn = connector->panel.backlight.edp.vesa.pwmgen_bit_count;
- int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
-
- freq = dev_priv->vbt.backlight.pwm_freq_hz;
- if (!freq) {
- drm_dbg_kms(_priv->drm,
- "Use panel default backlight frequency\n");
- return false;
- }
-
- fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
- f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
- fxp_actual = f << pn;
-
- /* Ensure frequency is within 25% of desired value */
- fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
- fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
-
- if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
- drm_dbg_kms(_priv->drm, "Actual frequency out of range\n");
- return false;
- }
-
- if (drm_dp_dpcd_writeb(_dp->aux,
- DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
- drm_dbg_kms(_priv->drm,
- "Failed to write aux backlight freq\n");
- return false;
- }
- return true;
-}
-
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state, u32 level)
@@ -459,9 +415,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
break;
}
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
- if (intel_dp_aux_vesa_set_pwm_freq(connector))
+ if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
+ if (drm_dp_dpcd_writeb(_dp->aux,
DP_EDP_BACKLIGHT_FREQ_SET,
+
panel->backlight.edp.vesa.pwm_freq_pre_divider) == 1)
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+ else
+ drm_dbg_kms(>drm, "Failed to write aux backlight
frequency\n");
+ }
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(_dp->aux,
@@ -482,6 +442,14 @@ static void intel_dp_aux_vesa_disable_backlight(const
struct drm_connector_state
false);
}
+/*
+ * Compute PWM frequency divider value based off the frequency provided to us
by the vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P =
[PATCH v6 2/9] drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP work
again, also because I'd rather not mix a tree-wide refactor like that in
with a patch series intended to be around introducing DP backlight helpers.
So, for now let's just handle the return values from each function
correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 41 +--
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 68bfe50ada59..1dbe38282ebe 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -107,7 +107,7 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector
*connector)
u8 tcon_cap[4];
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap,
sizeof(tcon_cap));
- if (ret < 0)
+ if (ret != sizeof(tcon_cap))
return false;
if (!(tcon_cap[1] & INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP))
@@ -137,7 +137,7 @@ intel_dp_aux_hdr_get_backlight(struct intel_connector
*connector, enum pipe pipe
u8 tmp;
u8 buf[2] = { 0 };
- if (drm_dp_dpcd_readb(_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS,
) < 0) {
+ if (drm_dp_dpcd_readb(_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS,
) != 1) {
drm_err(>drm, "Failed to read current backlight mode from
DPCD\n");
return 0;
}
@@ -153,7 +153,8 @@ intel_dp_aux_hdr_get_backlight(struct intel_connector
*connector, enum pipe pipe
return panel->backlight.max;
}
- if (drm_dp_dpcd_read(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf, sizeof(buf)) < 0) {
+ if (drm_dp_dpcd_read(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB, buf,
+sizeof(buf)) != sizeof(buf)) {
drm_err(>drm, "Failed to read brightness from DPCD\n");
return 0;
}
@@ -172,7 +173,8 @@ intel_dp_aux_hdr_set_aux_backlight(const struct
drm_connector_state *conn_state,
buf[0] = level & 0xFF;
buf[1] = (level & 0xFF00) >> 8;
- if (drm_dp_dpcd_write(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf, 4) < 0)
+ if (drm_dp_dpcd_write(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf,
+ sizeof(buf)) != sizeof(buf))
drm_err(dev, "Failed to write brightness level to DPCD\n");
}
@@ -203,7 +205,7 @@ intel_dp_aux_hdr_enable_backlight(const struct
intel_crtc_state *crtc_state,
u8 old_ctrl, ctrl;
ret = drm_dp_dpcd_readb(_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, _ctrl);
- if (ret < 0) {
+ if (ret != 1) {
drm_err(>drm, "Failed to read current backlight control
mode: %d\n", ret);
return;
}
@@ -221,7 +223,7 @@ intel_dp_aux_hdr_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
if (ctrl != old_ctrl)
- if (drm_dp_dpcd_writeb(_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, ctrl) < 0)
+ if (drm_dp_dpcd_writeb(_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, ctrl) != 1)
drm_err(>drm, "Failed to configure DPCD
brightness controls\n");
}
@@ -277,8 +279,7 @@ static void set_vesa_backlight_enable(struct intel_dp
*intel_dp, bool enable)
if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
return;
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- _val) < 0) {
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_DISPLAY_CONTROL_REGISTER);
return;
@@ -332,8 +333,8 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
- if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
-_val, sizeof(read_val)) < 0) {
+ if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val,
+sizeof(read_val)) != sizeof(read_val)) {
drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
@@ -365,8 +366,8 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
[PATCH v6 0/9] drm: Extract DPCD backlight helpers from i915, add support in nouveau
This series: * Cleans up i915's DPCD backlight code a little bit * Extracts i915's DPCD backlight code into a set of shared DRM helpers * Starts using those helpers in nouveau to add support to nouveau for DPCD backlight control v2 series-wide changes: * Rebase v3 series-wide changes: * Split up the changes to intel's backlight code into separate patches v4 series-wide changes: * Don't forget to actually include the patch that starts using these helpers in nouveau v5 series-wide changes: * Rebase * Use new drm_dbg_*() logging helpers v6 series-wide changes: * Add a bunch of R-bs that got dropped by accident Lyude Paul (9): drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculations drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight drm/i915/dpcd_bl: Move VESA backlight enabling code closer together drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT drm/i915/dpcd_bl: Print return codes for VESA backlight failures drm/dp: Extract i915's eDP backlight code into DRM helpers drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau drivers/gpu/drm/drm_dp_helper.c | 347 ++ .../drm/i915/display/intel_display_types.h| 2 +- .../drm/i915/display/intel_dp_aux_backlight.c | 329 ++--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 ++ drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 - drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +- drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 + include/drm/drm_dp_helper.h | 48 +++ 8 files changed, 622 insertions(+), 308 deletions(-) -- 2.31.1
Re: [Intel-gfx] [PATCH 06/27] drm/i915: Drop the CONTEXT_CLONE API
On Tue, May 4, 2021 at 3:50 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:27AM -0500, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation. It can be used as a short-cut for setparam(getparam()) for
> > things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
> > real userspace. It's used by a few IGT tests and that's it. Since it
> > doesn't add any real value (most of the stuff you can CLONE you can copy
> > in other ways), drop it.
> >
> > There is one thing that this API allows you to clone which you cannot
> > clone via getparam/setparam: timelines. However, timelines are an
> > implementation detail of i915 and not really something that needs to be
> > exposed to userspace. Also, sharing timelines between contexts isn't
> > obviously useful and supporting it has the potential to complicate i915
> > internally. It also doesn't add any functionality that the client can't
> > get in other ways. If a client really wants a shared timeline, they can
> > use a syncobj and set it as an in and out fence on every submit.
> >
> > Signed-off-by: Jason Ekstrand
> > Cc: Tvrtko Ursulin
>
> This aint gitlab MR, so please include a per-patch (and also per-revision)
> changelog summary here. With that added:
I don't think this patch has changed. I'll scroll through to make sure, though.
> Reviewed-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +-
> > .../drm/i915/gt/intel_execlists_submission.c | 28 ---
> > .../drm/i915/gt/intel_execlists_submission.h | 3 -
> > include/uapi/drm/i915_drm.h | 16 +-
> > 4 files changed, 6 insertions(+), 240 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index d6f342e605254..308a63f778faf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1958,207 +1958,14 @@ static int create_setparam(struct
> > i915_user_extension __user *ext, void *data)
> > return ctx_setparam(arg->fpriv, arg->ctx, );
> > }
> >
> > -static int clone_engines(struct i915_gem_context *dst,
> > - struct i915_gem_context *src)
> > +static int invalid_ext(struct i915_user_extension __user *ext, void *data)
> > {
> > - struct i915_gem_engines *clone, *e;
> > - bool user_engines;
> > - unsigned long n;
> > -
> > - e = __context_engines_await(src, _engines);
> > - if (!e)
> > - return -ENOENT;
> > -
> > - clone = alloc_engines(e->num_engines);
> > - if (!clone)
> > - goto err_unlock;
> > -
> > - for (n = 0; n < e->num_engines; n++) {
> > - struct intel_engine_cs *engine;
> > -
> > - if (!e->engines[n]) {
> > - clone->engines[n] = NULL;
> > - continue;
> > - }
> > - engine = e->engines[n]->engine;
> > -
> > - /*
> > - * Virtual engines are singletons; they can only exist
> > - * inside a single context, because they embed their
> > - * HW context... As each virtual context implies a single
> > - * timeline (each engine can only dequeue a single request
> > - * at any time), it would be surprising for two contexts
> > - * to use the same engine. So let's create a copy of
> > - * the virtual engine instead.
> > - */
> > - if (intel_engine_is_virtual(engine))
> > - clone->engines[n] =
> > - intel_execlists_clone_virtual(engine);
> > - else
> > - clone->engines[n] = intel_context_create(engine);
> > - if (IS_ERR_OR_NULL(clone->engines[n])) {
> > - __free_engines(clone, n);
> > - goto err_unlock;
> > - }
> > -
> > - intel_context_set_gem(clone->engines[n], dst);
> > - }
> > - clone->num_engines = n;
> > - i915_sw_fence_complete(>fence);
> > -
> > - /* Serialised by constructor */
> > - engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone,
> > 1));
> > - if (user_engines)
> > - i915_gem_context_set_user_engines(dst);
> > - else
> > - i915_gem_context_clear_user_engines(dst);
> > - return 0;
> > -
> > -err_unlock:
> > - i915_sw_fence_complete(>fence);
> > - return -ENOMEM;
> > -}
> > -
> > -static int clone_flags(struct i915_gem_context *dst,
> > -struct i915_gem_context *src)
> > -{
> > - dst->user_flags = src->user_flags;
> > - return 0;
> > -}
> > -
> > -static int clone_schedattr(struct i915_gem_context *dst,
> > -struct i915_gem_context *src)
> > -{
> > - dst->sched = src->sched;
> > - return 0;
> > -}
> > -
> >
Re: [PATCH 02/27] drm/i915: Stop storing the ring size in the ring pointer
On Tue, May 4, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:23AM -0500, Jason Ekstrand wrote:
> > Previously, we were storing the ring size in the ring pointer before it
> > was actually allocated. We would then guard setting the ring size on
> > checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
> > only saves us a few bytes on something that already burns at least 4K.
> > Instead, this patch adds a new ring_size field and makes everything use
> > that.
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
> > drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
> > drivers/gpu/drm/i915/gt/intel_context.h | 5 -
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +-
> > drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++-
> > 9 files changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index e52b85b8f923d..2ba4c7e4011b4 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -211,8 +211,7 @@ static void intel_context_set_gem(struct intel_context
> > *ce,
> > GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
> > RCU_INIT_POINTER(ce->gem_context, ctx);
> >
> > - if (!test_bit(CONTEXT_ALLOC_BIT, >flags))
> > - ce->ring = __intel_context_ring_size(SZ_16K);
> > + ce->ring_size = SZ_16K;
> >
> > if (rcu_access_pointer(ctx->vm)) {
> > struct i915_address_space *vm;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 17cf2640b082b..342fa7daa08b5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -372,7 +372,8 @@ intel_context_init(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> > ce->engine = engine;
> > ce->ops = engine->cops;
> > ce->sseu = engine->sseu;
> > - ce->ring = __intel_context_ring_size(SZ_4K);
> > + ce->ring = NULL;
> > + ce->ring_size = SZ_4K;
> >
> > ewma_runtime_init(>runtime.avg);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > b/drivers/gpu/drm/i915/gt/intel_context.h
> > index f83a73a2b39fc..b10cbe8fee992 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -175,11 +175,6 @@ int intel_context_prepare_remote_request(struct
> > intel_context *ce,
> >
> > struct i915_request *intel_context_create_request(struct intel_context
> > *ce);
> >
> > -static inline struct intel_ring *__intel_context_ring_size(u64 sz)
> > -{
> > - return u64_to_ptr(struct intel_ring, sz);
> > -}
> > -
> > static inline bool intel_context_is_barrier(const struct intel_context *ce)
> > {
> > return test_bit(CONTEXT_BARRIER_BIT, >flags);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index ed8c447a7346b..90026c1771055 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -82,6 +82,7 @@ struct intel_context {
> > spinlock_t signal_lock; /* protects signals, the list of requests */
> >
> > struct i915_vma *state;
> > + u32 ring_size;
> > struct intel_ring *ring;
> > struct intel_timeline *timeline;
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index e86897cde9846..63193c80fb117 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -845,7 +845,7 @@ int lrc_alloc(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> > if (IS_ERR(vma))
> > return PTR_ERR(vma);
> >
> > - ring = intel_engine_create_ring(engine, (unsigned long)ce->ring);
> > + ring = intel_engine_create_ring(engine, ce->ring_size);
> > if (IS_ERR(ring)) {
> > err = PTR_ERR(ring);
> > goto err_vma;
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > index 1081cd36a2bd3..01d9896dd4844 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > @@ -2793,7 +2793,7 @@ static int __live_preempt_ring(struct intel_engine_cs
> > *engine,
> > goto err_ce;
> > }
> >
> > - tmp->ring = __intel_context_ring_size(ring_sz);
> > + tmp->ring_size = ring_sz;
> >
> > err = intel_context_pin(tmp);
> >
Re: [git pull] drm fixes for 5.13-rc2
The pull request you sent on Fri, 14 May 2021 12:34:38 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-05-14 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b5304a4f9ad88a712c26c63691a99c0b9b1b5dc6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] drm fixes for 5.13-rc2
On Thu, May 13, 2021 at 7:34 PM Dave Airlie wrote: > > Just realised I got the tag header wrong, these are the rc2 fixes. Heh. The tag message also says: > vc4: > - drop an used function which just makes me think you may have started drinking early ;) I fixed it up. Skål! Linus
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 10:29 AM Linus Torvalds
wrote:
>
> So why not just say "that clearly already doesn't work, so make it
> explicitly not permitted"?
IOW, something like this would seem fairly simple and straightforward:
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 01645e87b3d5..f24e627b7402 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1171,8 +1171,13 @@ static inline int resize_screen(struct
vc_data *vc, int width, int height,
/* Resizes the resolution of the display adapater */
int err = 0;
- if (vc->vc_mode != KD_GRAPHICS && vc->vc_sw->con_resize)
+ if (vc->vc_sw->con_resize) {
+ // If we have a resize function but are in KD_GRAPHICS mode,
+ // we can't actually do a resize and need to error out.
+ if (vc->vc_mode == KD_GRAPHICS)
+ return -EINVAL;
err = vc->vc_sw->con_resize(vc, width, height, user);
+ }
return err;
}
not tested, but it looks ObviouslyCorrect(tm), and since we know the
old case didn't work right, it seems very safe to do.
Linus
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 9:20 AM Tetsuo Handa wrote: > > Currently it is impossible to control upper limit of rows/columns values > based on amount of memory reserved for the graphical screen, for > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not > already KD_GRAPHICS Honestly, the saner approach would seem to be to simply error out if vc_mode is KD_GRAPHICS. Doing VT_RESIZE while in KD_GRAPHICS mode seems _very_ questionable, and is clearly currently very buggy. So why not just say "that clearly already doesn't work, so make it explicitly not permitted"? Linus
Re: [PATCH] drm/ingenic: Fix pixclock rate for 24-bit serial panels
Am 13.05.21 um 14:29 schrieb Paul Cercueil:
Hi,
Almost two months later,
Le mar., mars 23 2021 at 14:40:08 +, Paul Cercueil
a écrit :
When using a 24-bit panel on a 8-bit serial bus, the pixel clock
requested by the panel has to be multiplied by 3, since the subpixels
are shifted sequentially.
The code (in ingenic_drm_encoder_atomic_check) already computed
crtc_state->adjusted_mode->crtc_clock accordingly, but clk_set_rate()
used crtc_state->adjusted_mode->clock instead.
Fixes: 28ab7d35b6e0 ("drm/ingenic: Properly compute timings when using
a 3x8-bit panel")
Cc: sta...@vger.kernel.org # v5.10
Signed-off-by: Paul Cercueil
Can I get an ACK for my patch?
Acked-by: Thomas Zimmermann
Thanks!
-Paul
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index d60e1eefc9d1..cba68bf52ec5 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -342,7 +342,7 @@ static void ingenic_drm_crtc_atomic_flush(struct
drm_crtc *crtc,
if (priv->update_clk_rate) {
mutex_lock(>clk_mutex);
clk_set_rate(priv->pix_clk,
- crtc_state->adjusted_mode.clock * 1000);
+ crtc_state->adjusted_mode.crtc_clock * 1000);
priv->update_clk_rate
= false;
mutex_unlock(>clk_mutex);
}
--
2.30.2
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Fri, May 14, 2021 at 11:36:37AM -0500, Jason Ekstrand wrote: > On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin > wrote: > > > > On 06/05/2021 20:13, Matthew Brost wrote: > > > Basic GuC submission support. This is the first bullet point in the > > > upstreaming plan covered in the following RFC [1]. > > > > > > At a very high level the GuC is a piece of firmware which sits between > > > the i915 and the GPU. It offloads some of the scheduling of contexts > > > from the i915 and programs the GPU to submit contexts. The i915 > > > communicates with the GuC and the GuC communicates with the GPU. > > > > > > GuC submission will be disabled by default on all current upstream > > > platforms behind a module parameter - enable_guc. A value of 3 will > > > enable submission and HuC loading via the GuC. GuC submission should > > > work on all gen11+ platforms assuming the GuC firmware is present. > > > > Some thoughts mostly relating to future platforms where GuC will be the > > only option, and to some extent platforms where it will be possible to > > turn it on for one reason or another. > > > > Debuggability - in the context of having an upstream way/tool for > > capturing and viewing GuC logs usable for attaching to bug reports. > > > > Currently i915 logs, can provide traces via tracepoints and trace > > printk, and GPU error capture state, which provides often sufficient > > trail of evidence to debug issues. > > > > We need to make sure GuC does is not a black box in this respect. By > > this I mean it does not hide a large portion of the execution flows from > > upstream observability. > > I agree here. If GuC suddenly makes submission issues massively > harder to debug then that's a regression vs. execlists. I don't know > what the solution there is but I think the concern is valid. > Replied to Tvrtko with detailed answers. The TL;DR is agree with basically everything he said and we have plans address it all and everything must be addressed before the GuC can be turned on by default. Matt > > This could mean a tool in IGT to access/capture GuC logs and update bug > > filing instructions. > > > > Leading from here is probably the need for the GuC firmware team to > > cross the internal-upstream boundary and deal with such bug reports on > > upstream trackers. Upstream GuC is unlikely to work if we don't have > > such plan and commitment. > > I mostly agree here as well. I'm not sure it'll actually happen but > I'd like anyone who writes code which impacts Linux to be active in > upstream bug trackers. > > > Also leading from here is the need for GPU error capture to be on par > > from day one which is I believe still not there in the firmware. > > This one has me genuinely concerned. I've heard rumors that we don't > have competent error captures with GuC yet. From the Mesa PoV, this > is a non-starter. We can't be asked to develop graphics drivers with > no error capture. > > The good news is that, based on my understanding, it shouldn't be > terrible to support. We just need the GuC to grab all the registers > for us and shove them in a buffer somewhere before it resets the GPU > and all that data is lost. I would hope the Windows people have > already done that and we just need to hook it up. If not, there may > be some GuC engineering required here. > > > Another, although unrelated, missing feature on my wish list is firmware > > support for wiring up accurate engine busyness stats to i915 PMU. I > > believe this is also being worked on but I don't know when is the > > expected delivery. > > > > If we are tracking a TODO list of items somewhere I think these ones > > should be definitely considered. > > Yup, let's get it all in the ToDo and not flip GuC on by default in > the wild until it's all checked off. > > --Jason
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Fri, May 14, 2021 at 12:11:56PM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Basic GuC submission support. This is the first bullet point in the > > upstreaming plan covered in the following RFC [1]. > > > > At a very high level the GuC is a piece of firmware which sits between > > the i915 and the GPU. It offloads some of the scheduling of contexts > > from the i915 and programs the GPU to submit contexts. The i915 > > communicates with the GuC and the GuC communicates with the GPU. > > > > GuC submission will be disabled by default on all current upstream > > platforms behind a module parameter - enable_guc. A value of 3 will > > enable submission and HuC loading via the GuC. GuC submission should > > work on all gen11+ platforms assuming the GuC firmware is present. > > Some thoughts mostly relating to future platforms where GuC will be the only > option, and to some extent platforms where it will be possible to turn it on > for one reason or another. > > Debuggability - in the context of having an upstream way/tool for capturing > and viewing GuC logs usable for attaching to bug reports. > Agree. We have discussed this internally as an upstream requirement for quite sometime. > Currently i915 logs, can provide traces via tracepoints and trace printk, > and GPU error capture state, which provides often sufficient trail of > evidence to debug issues. > If we do this right, we should have something the same with GuC submission. > We need to make sure GuC does is not a black box in this respect. By this I > mean it does not hide a large portion of the execution flows from upstream > observability. > > This could mean a tool in IGT to access/capture GuC logs and update bug > filing instructions. > We have a few internal tools decode the GuC logs. One of these tools will be open sourced and on a public repo. We just need to decide which tool and make sure that tool works across all the distros. > Leading from here is probably the need for the GuC firmware team to cross > the internal-upstream boundary and deal with such bug reports on upstream > trackers. Upstream GuC is unlikely to work if we don't have such plan and > commitment. > I think we can land this code first as it is going be disabled by default. Certainly once we turn it on by default we need to have everything in place that you mention in this email. > Also leading from here is the need for GPU error capture to be on par from > day one which is I believe still not there in the firmware. > We are missing a register dump from the GuC on reset. No other way to say this than this has been huge miss by the i915 / GuC teams. This is something we absolutely need and it hasn't gotten done. I'll push on this and hopefully we can land this feature soon. > Another, although unrelated, missing feature on my wish list is firmware > support for wiring up accurate engine busyness stats to i915 PMU. I believe > this is also being worked on but I don't know when is the expected delivery. > This is landing this week I believe. Next upstream post should include an updated GuC firmware + code in the i915 that hooks into the PMU stats. Matt > If we are tracking a TODO list of items somewhere I think these ones should > be definitely considered. > > Regards, > > Tvrtko
Re: thinkpad x1 carbon display flickering after update to 5.12. good on 5.11.x (i915)
Hello. On Fri, May 14, 2021 at 10:24:26AM +0200, Thomas Stein wrote: > After upgrading to linux 5.12 the display on my X1 Carbon Gen 2 starts to > flicker. Well actually it seems to turn off and on again and again. Here a > link to a video a person posted who has the same issue as me obviousely. > https://linuxove.com/thinkpad-x1-carbon-gen-3-display-flickering-on-linux-kernel-5-12/ > > This happens without having Xorg running too. So it can't be related to > Xorg. The kernel boots and after a few seconds, the kernel messages scoll > through, the flickering starts. Nothing special in dmesg. > > dmesg: > > himbeere@rather ~ $ dmesg | grep i915 > [0.713595] i915 :00:02.0: vgaarb: deactivate vga console > [0.720280] i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > [0.741494] i915 :00:02.0: [drm] Panel advertises DPCD backlight > support, but VBT disagrees. If your backlight controls don't work try > booting with i915.enable_dpcd_backlight=1. If your machine needs this, > please file a _new_ bug report on drm/i915, see > https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for > details. > [1.864837] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on > minor 0 > [1.875907] fbcon: i915drmfb (fb0) is primary device > [3.158255] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device > himbeere@rather ~ $ > > Downgrading to 5.11 solves the issue for me. Any ideas? Does [1] fix your issue? [1] https://cgit.freedesktop.org/drm-tip/patch/?id=acca7762eb71bc05a8f28d29320d193150051f79 -- Oleksandr Natalenko (post-factum)
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Basic GuC submission support. This is the first bullet point in the > > upstreaming plan covered in the following RFC [1]. > > > > At a very high level the GuC is a piece of firmware which sits between > > the i915 and the GPU. It offloads some of the scheduling of contexts > > from the i915 and programs the GPU to submit contexts. The i915 > > communicates with the GuC and the GuC communicates with the GPU. > > > > GuC submission will be disabled by default on all current upstream > > platforms behind a module parameter - enable_guc. A value of 3 will > > enable submission and HuC loading via the GuC. GuC submission should > > work on all gen11+ platforms assuming the GuC firmware is present. > > Some thoughts mostly relating to future platforms where GuC will be the > only option, and to some extent platforms where it will be possible to > turn it on for one reason or another. > > Debuggability - in the context of having an upstream way/tool for > capturing and viewing GuC logs usable for attaching to bug reports. > > Currently i915 logs, can provide traces via tracepoints and trace > printk, and GPU error capture state, which provides often sufficient > trail of evidence to debug issues. > > We need to make sure GuC does is not a black box in this respect. By > this I mean it does not hide a large portion of the execution flows from > upstream observability. I agree here. If GuC suddenly makes submission issues massively harder to debug then that's a regression vs. execlists. I don't know what the solution there is but I think the concern is valid. > This could mean a tool in IGT to access/capture GuC logs and update bug > filing instructions. > > Leading from here is probably the need for the GuC firmware team to > cross the internal-upstream boundary and deal with such bug reports on > upstream trackers. Upstream GuC is unlikely to work if we don't have > such plan and commitment. I mostly agree here as well. I'm not sure it'll actually happen but I'd like anyone who writes code which impacts Linux to be active in upstream bug trackers. > Also leading from here is the need for GPU error capture to be on par > from day one which is I believe still not there in the firmware. This one has me genuinely concerned. I've heard rumors that we don't have competent error captures with GuC yet. From the Mesa PoV, this is a non-starter. We can't be asked to develop graphics drivers with no error capture. The good news is that, based on my understanding, it shouldn't be terrible to support. We just need the GuC to grab all the registers for us and shove them in a buffer somewhere before it resets the GPU and all that data is lost. I would hope the Windows people have already done that and we just need to hook it up. If not, there may be some GuC engineering required here. > Another, although unrelated, missing feature on my wish list is firmware > support for wiring up accurate engine busyness stats to i915 PMU. I > believe this is also being worked on but I don't know when is the > expected delivery. > > If we are tracking a TODO list of items somewhere I think these ones > should be definitely considered. Yup, let's get it all in the ToDo and not flip GuC on by default in the wild until it's all checked off. --Jason
Re: [bug report] drm: remove usage of drm_pci_alloc/free
On Fri, May 14, 2021 at 8:13 AM Joseph Kogut wrote: > > Hi Dan, > > On Fri, May 14, 2021 at 6:54 AM Dan Carpenter > wrote: > > > > Hello Joseph Kogut, > > > > The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free" > > from Apr 22, 2021, leads to the following static checker warning: > > > > drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci() > > warn: inconsistent returns '>struct_mutex'. > > Locked on : 988 > > Unlocked on: 938,944,951,959,973,1005,1042,1060,1090 > > Do you mind if I copy this portion of the bug report in the commit message?
Re: [RFC PATCH 00/97] Basic GuC submission support in the i915
Pulling a few threads together... On Mon, May 10, 2021 at 1:39 PM Francisco Jerez wrote: > > I agree with Martin on this. Given that using GuC currently involves > making your open-source graphics stack rely on a closed-source > cryptographically-protected blob in order to submit commands to the GPU, > and given that it is /still/ possible to use the GPU without it, I'd > expect some strong material justification for making the switch (like, > it improves performance of test-case X and Y by Z%, or, we're truly > sorry but we cannot program your GPU anymore with a purely open-source > software stack). Any argument based on the apparent direction of the > wind doesn't sound like a material engineering reason to me, and runs > the risk of being self-fulfilling if it leads us to do the worse thing > for our users just because we have the vague feeling that it is the > general trend, even though we may have had the means to obtain a better > compromise for them. I think it's important to distinguish between landing code to support GuC submission and requiring it in order to use the GPU. We've got the execlist back-end and it's not going anywhere, at least not for older hardware, and it will likely keep working as long as execlists remain in the hardware. What's being proposed here is a new back-end which, yes, depends on firmware and can be used for more features. I'm well aware of the slippery slope argument that's implicitly being used here even if no one is actually saying it: If we land GuC support in i915 in any form then Intel HW engineers will say "See, Linux supports GuC now; we can rip out execlists" and we'll end up in the dystopia of closed-source firmware. If upstream continues to push back on GuC in any form then they'll be forced to keep execlists. I'll freely admit that there is probably some truth to this. However, I really doubt that it's going to work long-term. If the HW architects are determined enough to rip it out, they will. If GuC is really inevitable, then it's in our best interests to land at least beta support earlier. There are a lot of questions that people have brought up around back-ports, dealing with stable kernels, stability concerns, etc. The best way to sort those out is to land the code and start dealing with the issues. We can't front-load solving every possible issue or the code will never land. But maybe that's people's actual objective? On Wed, May 12, 2021 at 1:26 AM Martin Peres wrote: > > On 11/05/2021 19:39, Matthew Brost wrote: > > On Tue, May 11, 2021 at 08:26:59AM -0700, Bloomfield, Jon wrote: > >>> On 10/05/2021 19:33, Daniel Vetter wrote: > On Mon, May 10, 2021 at 3:55 PM Martin Peres > >>> wrote: > >>> > >>> However, if the GuC is actually helping i915, then why not open source > >>> it and drop all the issues related to its stability? Wouldn't it be the > >>> perfect solution, as it would allow dropping execlist support for newer > >>> HW, and it would eliminate the concerns about maintenance of stable > >>> releases of Linux? I would like to see that happen. I know there was some chatter about it for a while and then the discussions got killed. I'm not sure what happened, to be honest. However, I don't think we can make any guarantees or assumptions there, I'm afraid. :-( > >> That the major version of the FW is high is not due to bugs - Bugs don't > >> trigger major version bumps anyway. > > Of course, where did I say they would? I think the concern here is that old kernels will require old major GuC versions because interfaces won't be backwards-compatible and then those kernels won't get bug fixes. That's a legitimate concern. Given the Linux usage model, I think it's fair to require either backwards-compatibility with GuC interfaces and validation of that backwards-compatibility or stable releases with bug fixes for a good long while. I honestly can't say whether or not we've really scoped that. Jon? > >> We have been using GuC as the sole mechanism for submission on Windows > >> since Gen8, and it has proven very reliable. This is in large part because > >> it is simple, and designed from day 1 as a cohesive solution alongside the > >> hardware. There are going to be differences in the usage patterns that i915 and Windows will hit when it comes to the subtle details of how we bang on the GuC rings. Those will likely lead to bugs on Linux that don't show up on Windows so "it works on Windows" doesn't mean we're headed for a bug-free future. It means we have an existence proof that firmware-based submission can be very reliable. However, I don't think anyone on this thread is really questioning that. > Exactly, the GuC was designed with Windows' GPU model... which is not > directly applicable to Linux. Also, Windows does not care as much about > submission latency, whereas most Linux users still depend on glamor for > 2D acceleration which is pretty much the biggest stress test for command > submission latency.
Re: [PATCH v7 05/16] drm/amdgpu: Handle IOMMU enabled case.
Makes sense - will update.
Andrey
On 2021-05-14 12:25 p.m., Felix Kuehling wrote:
Maybe this patch needs a better explanation how the GART and IH changes
relate to IOMMU or what's the problem this is meant to fix. Just looking
at the patch I don't see the connection. Looks like just a bunch of
refactoring to me.
Regards,
Felix
Am 2021-05-14 um 10:41 a.m. schrieb Andrey Grodzovsky:
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
v7:
Drop amdgpu_gart_fini
In amdgpu_ih_ring_fini do uncinditional check (!ih->ring)
to avoid freeing uniniitalized rings.
Call amdgpu_ih_ring_fini unconditionally.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 +
drivers/gpu/drm/amd/amdgpu/cik_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/si_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4
18 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 18598eda18f6..a0bff4713672 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3256,7 +3256,6 @@ static const struct attribute
*amdgpu_dev_attributes[] = {
NULL
};
-
/**
* amdgpu_device_init - initialize the driver
*
@@ -3698,12 +3697,13 @@ void amdgpu_device_fini_hw(struct
amdgpu_device *adev)
amdgpu_ucode_sysfs_fini(adev);
sysfs_remove_files(>dev->kobj, amdgpu_dev_attributes);
-
amdgpu_fbdev_fini(adev);
amdgpu_irq_fini_hw(adev);
amdgpu_device_ip_fini_early(adev);
+
+ amdgpu_gart_dummy_page_fini(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index c5a9a4fb10d2..6460cf723f0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct
amdgpu_device *adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
@@ -365,15 +365,3 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
return 0;
}
-
-/**
- * amdgpu_gart_fini - tear down the driver info for managing the gart
- *
- * @adev: amdgpu_device pointer
- *
- * Tear down the gart driver info and free the dummy page (all asics).
- */
-void amdgpu_gart_fini(struct amdgpu_device *adev)
-{
- amdgpu_gart_dummy_page_fini(adev);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
index a25fe97b0196..030b9d4c736a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
@@ -57,7 +57,7 @@ void amdgpu_gart_table_vram_free(struct
amdgpu_device *adev);
int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev);
void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev);
int amdgpu_gart_init(struct amdgpu_device *adev);
-void amdgpu_gart_fini(struct amdgpu_device *adev);
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev);
int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
int pages);
int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index faaa6aa2faaf..433469ace6f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -115,9 +115,11 @@ int amdgpu_ih_ring_init(struct amdgpu_device
*adev, struct amdgpu_ih_ring *ih,
*/
void amdgpu_ih_ring_fini(struct amdgpu_device *adev, struct
amdgpu_ih_ring *ih)
{
+
+ if (!ih->ring)
+ return;
+
if (ih->use_bus_addr) {
- if (!ih->ring)
- return;
/* add 8
Re: [PATCH v7 05/16] drm/amdgpu: Handle IOMMU enabled case.
Maybe this patch needs a better explanation how the GART and IH changes
relate to IOMMU or what's the problem this is meant to fix. Just looking
at the patch I don't see the connection. Looks like just a bunch of
refactoring to me.
Regards,
Felix
Am 2021-05-14 um 10:41 a.m. schrieb Andrey Grodzovsky:
> Ping
>
> Andrey
>
> On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
>> Handle all DMA IOMMU gropup related dependencies before the
>> group is removed.
>>
>> v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
>> v6: Drop the BO unamp list
>> v7:
>> Drop amdgpu_gart_fini
>> In amdgpu_ih_ring_fini do uncinditional check (!ih->ring)
>> to avoid freeing uniniitalized rings.
>> Call amdgpu_ih_ring_fini unconditionally.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 14 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 --
>> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 +
>> drivers/gpu/drm/amd/amdgpu/cik_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/cz_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 4
>> drivers/gpu/drm/amd/amdgpu/si_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
>> drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4
>> 18 files changed, 13 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 18598eda18f6..a0bff4713672 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3256,7 +3256,6 @@ static const struct attribute
>> *amdgpu_dev_attributes[] = {
>> NULL
>> };
>> -
>> /**
>> * amdgpu_device_init - initialize the driver
>> *
>> @@ -3698,12 +3697,13 @@ void amdgpu_device_fini_hw(struct
>> amdgpu_device *adev)
>> amdgpu_ucode_sysfs_fini(adev);
>> sysfs_remove_files(>dev->kobj, amdgpu_dev_attributes);
>> -
>> amdgpu_fbdev_fini(adev);
>> amdgpu_irq_fini_hw(adev);
>> amdgpu_device_ip_fini_early(adev);
>> +
>> + amdgpu_gart_dummy_page_fini(adev);
>> }
>> void amdgpu_device_fini_sw(struct amdgpu_device *adev)
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> index c5a9a4fb10d2..6460cf723f0a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> @@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct
>> amdgpu_device *adev)
>> *
>> * Frees the dummy page used by the driver (all asics).
>> */
>> -static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
>> +void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
>> {
>> if (!adev->dummy_page_addr)
>> return;
>> @@ -365,15 +365,3 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
>> return 0;
>> }
>> -
>> -/**
>> - * amdgpu_gart_fini - tear down the driver info for managing the gart
>> - *
>> - * @adev: amdgpu_device pointer
>> - *
>> - * Tear down the gart driver info and free the dummy page (all asics).
>> - */
>> -void amdgpu_gart_fini(struct amdgpu_device *adev)
>> -{
>> - amdgpu_gart_dummy_page_fini(adev);
>> -}
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> index a25fe97b0196..030b9d4c736a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> @@ -57,7 +57,7 @@ void amdgpu_gart_table_vram_free(struct
>> amdgpu_device *adev);
>> int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev);
>> void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev);
>> int amdgpu_gart_init(struct amdgpu_device *adev);
>> -void amdgpu_gart_fini(struct amdgpu_device *adev);
>> +void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev);
>> int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
>> int pages);
>> int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> index faaa6aa2faaf..433469ace6f4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> @@ -115,9 +115,11 @@ int amdgpu_ih_ring_init(struct amdgpu_device
>> *adev, struct amdgpu_ih_ring *ih,
>> */
>> void
[PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
syzbot is reporting that a local user with the framebuffer console can
crash the kernel [1], for ioctl(VT_RESIZE) allows a TTY to set arbitrary
rows/columns values regardless of amount of memory reserved for
the graphical screen.
--
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
const int fd = open("/dev/char/4:1", O_RDWR);
struct vt_sizes vt = { 0x4100, 2 };
ioctl(fd, KDSETMODE, KD_GRAPHICS);
ioctl(fd, VT_RESIZE, );
ioctl(fd, KDSETMODE, KD_TEXT);
return 0;
}
--
Currently it is impossible to control upper limit of rows/columns values
based on amount of memory reserved for the graphical screen, for
resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
already KD_GRAPHICS. I don't know the reason, and this condition predates
the git history. Even if it turns out to be safe to always call this
callback, we will need to involve another callback via "struct fb_ops" for
checking the upper limits from fbcon_resize(). As a result, we will need
to modify
drivers/tty/vt/vt.c
drivers/video/fbdev/core/fbcon.c
drivers/video/fbdev/vga16fb.c
include/linux/fb.h
files only for checking rows/columns values passed to ioctl(VT_RESIZE)
request.
Therefore, instead of introducing such a complicated callback chain, avoid
this problem by simply checking whether the address to read or write is in
[VGA_FB_PHYS, VGA_FB_PHYS + VGA_FB_PHYS_LEN) range.
[1] https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
---
drivers/video/fbdev/vga16fb.c | 54 +++
1 file changed, 36 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
index e2757ff1c23d..13732a3b1d69 100644
--- a/drivers/video/fbdev/vga16fb.c
+++ b/drivers/video/fbdev/vga16fb.c
@@ -98,6 +98,18 @@ static const struct fb_fix_screeninfo vga16fb_fix = {
.accel = FB_ACCEL_NONE
};
+/*
+ * Verify that the address to read or write is in [VGA_FB_PHYS, VGA_FB_PHYS +
VGA_FB_PHYS_LEN)
+ * range, for ioctl(VT_RESIZE) allows a TTY to set arbitrary rows/columns
values which will crash
+ * the kernel due to out of bounds access when trying to redraw the screen.
+ */
+static inline bool is_valid_iomem(const struct fb_info *info, const char
__iomem *where)
+{
+ return info->screen_base <= where && where < info->screen_base +
VGA_FB_PHYS_LEN;
+}
+
+#define IS_SAFE(where) is_valid_iomem(info, (where))
+
/* The VGA's weird architecture often requires that we read a byte and
write a byte to the same location. It doesn't matter *what* byte
we write, however. This is because all the action goes on behind
@@ -851,7 +863,7 @@ static void vga_8planes_fillrect(struct fb_info *info,
const struct fb_fillrect
int x;
/* we can do memset... */
-for (x = width; x > 0; --x) {
+ for (x = width; x > 0 && IS_SAFE(where); --x) {
writeb(rect->color, where);
where++;
}
@@ -864,7 +876,7 @@ static void vga_8planes_fillrect(struct fb_info *info,
const struct fb_fillrect
oldop = setop(0x18);
oldsr = setsr(0xf);
setmask(0x0F);
-for (y = 0; y < rect->height; y++) {
+ for (y = 0; y < rect->height && IS_SAFE(where) && IS_SAFE(where
+ 1); y++) {
rmw(where);
rmw(where+1);
where += info->fix.line_length;
@@ -919,7 +931,7 @@ static void vga16fb_fillrect(struct fb_info *info, const
struct fb_fillrect *rec
setmask(0xff);
while (height--) {
- for (x = 0; x < width; x++) {
+ for (x = 0; x < width && IS_SAFE(dst);
x++) {
writeb(0, dst);
dst++;
}
@@ -935,7 +947,7 @@ static void vga16fb_fillrect(struct fb_info *info, const
struct fb_fillrect *rec
setmask(0xff);
while (height--) {
- for (x = 0; x < width; x++) {
+ for (x = 0; x < width && IS_SAFE(dst);
x++) {
rmw(dst);
dst++;
}
@@ -975,7 +987,7 @@ static void vga_8planes_copyarea(struct fb_info *info,
const struct fb_copyarea
dest = info->screen_base + dx + area->dy *
info->fix.line_length;
src = info->screen_base + sx +
Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
On 14/05/2021 15:48, Neil Armstrong wrote: > On 13/05/2021 16:55, Ezequiel Garcia wrote: >> Hi Neil, >> >> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote: >>> >>> Hi, >>> >>> On 21/04/2021 07:28, Nicolas Boichat wrote: Hi! This is just a rebase of the v11, untested (but it seems like Neil Armstrong recently tested it), with small changes in binding and dts. v11 cover follows: Follow-up on the v5 [1], things have gotten significantly better in the last year, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ [2] https://crrev.com/c/2608070 Changes in v13: - devfreq: Fix conflict resolution mistake when rebasing, didn't even compile. Oops. Changes in v12: - binding: Fix min/maxItems logic (Rob Herring) - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). Changes in v11: - binding: power-domain-names not power-domainS-names - mt8183*.dts: remove incorrect supply-names Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. - Add gpu regulators to kukui dtsi as well. - Power domains are now attached to spm, not scpsys - Drop R-B. - devfreq: New change - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too. Changes in v5: - Rename "2d" power domain to "core2" - Rename "2d" power domain to "core2" (keep R-B again). - Change power domain name from 2d to core2. Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) - Add power-domain-names to describe the 3 domains. (kept Alyssa's reviewed-by as the change is minor) - Add power domain names. Changes in v3: - Match mt8183-mali instead of bifrost, as we require special handling for the 2 regulators and 3 power domains. Changes in v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml| 30 - arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 7 files changed, 168 insertions(+), 1 deletion(-) >>> >>> Seems this version is ready to be applied if we get a review on the DT ? >>> >>> Mathias ? could you have a look ? >>> >> >> Given Rob has Acked the DT bindings, I think it's OK to apply patches >> 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes. >> >> My two unsolicited cents :-) You make a convincing point - and if everyone is happy for the DT changes to be handled separately I don't see a reason for the other patches to be held up. > Yeah sure, is there a panfrost maintainer in the room ? I can apply them if > you ack me. I seem to be applying most Panfrost changes these days, so I'll save you the effort and push 1,3,4 to drm-misc-next. Thanks, Steve
Re: [bug report] drm: remove usage of drm_pci_alloc/free
Hi Dan,
On Fri, May 14, 2021 at 6:54 AM Dan Carpenter wrote:
>
> Hello Joseph Kogut,
>
> The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free"
> from Apr 22, 2021, leads to the following static checker warning:
>
> drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
> warn: inconsistent returns '>struct_mutex'.
> Locked on : 988
> Unlocked on: 938,944,951,959,973,1005,1042,1060,1090
>
> drivers/gpu/drm/drm_bufs.c
>965 temp_pagelist = kmalloc_array(dma->page_count + (count <<
> page_order),
>966sizeof(*dma->pagelist),
>967GFP_KERNEL);
>968 if (!temp_pagelist) {
>969 kfree(entry->buflist);
>970 kfree(entry->seglist);
>971 mutex_unlock(>struct_mutex);
>972 atomic_dec(>buf_alloc);
>973 return -ENOMEM;
>
> There is a bunch of clean up happenning on the existing returns.
>
>974 }
>975 memcpy(temp_pagelist,
>976 dma->pagelist, dma->page_count *
> sizeof(*dma->pagelist));
>977 DRM_DEBUG("pagelist: %d entries\n",
>978dma->page_count + (count << page_order));
>979
>980 entry->buf_size = size;
>981 entry->page_order = page_order;
>982 byte_count = 0;
>983 page_count = 0;
>984
>985 while (entry->buf_count < count) {
>986 dmah = kmalloc(sizeof(drm_dma_handle_t), GFP_KERNEL);
>987 if (!dmah)
>988 return -ENOMEM;
>
> This new return has no clean up. We a mutex_unlock(>struct_mutex).
>
>989
>990 dmah->size = total;
>991 dmah->vaddr = dma_alloc_coherent(dev->dev,
>992 dmah->size,
>993 >busaddr,
>994 GFP_KERNEL);
>995 if (!dmah->vaddr) {
>996 kfree(dmah);
>997
>998 /* Set count correctly so we free the proper
> amount. */
>999 entry->buf_count = count;
> 1000 entry->seg_count = count;
> 1001 drm_cleanup_buf_error(dev, entry);
> 1002 kfree(temp_pagelist);
> 1003 mutex_unlock(>struct_mutex);
> 1004 atomic_dec(>buf_alloc);
> 1005 return -ENOMEM;
> 1006 }
> 1007 entry->seglist[entry->seg_count++] = dmah;
> 1008 for (i = 0; i < (1 << page_order); i++) {
> 1009 DRM_DEBUG("page %d @ 0x%08lx\n",
>
> regards,
> dan carpenter
Thanks for the report, I'll follow up with a patch to fix this.
Best,
Joseph
Re: [PATCH 0/7] Per client engine busyness
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin: On 14/05/2021 15:56, Christian König wrote: Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. Well I just double checked and that is not correct. Could be that i915 has some special code for that, but on my laptop I only see the X server under the "clients" debugfs file. Yes we have special code in i915 for this. Part of this series we are discussing here. Ah, yeah you should mention that. Could we please separate that into common code instead? Cause I really see that as a bug in the current handling independent of the discussion here. As far as I know all IOCTLs go though some common place in DRM anyway. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. Completely agree. The key point is you either need to have all references to an open fd, or at least track whoever last used that fd. At least the last time I looked even the fs layer didn't know which fd is open by which process. So there wasn't really any alternative to the lsof approach. I asked you about the use case you have in mind which you did not answer. Otherwise I don't understand when do you need to walk all files. What information you want to get? Per fd debugging information, e.g. instead of the top use case you know which process you want to look at. For the use case of knowing which DRM file is using how much GPU time on engine X we do not need to walk all open files either with my sysfs approach or the proc approach from Chris. (In the former case we optionally aggregate by PID at presentation time, and in the latter case aggregation is implicit.) I'm unsure if we should go with the sysfs, proc or some completely different approach. In general it would be nice to have a way to find all the fd references for an open inode. Regards, Christian. Regards, Tvrtko
Re: [PATCH 0/7] Per client engine busyness
On 14/05/2021 15:56, Christian König wrote: Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. Well I just double checked and that is not correct. Could be that i915 has some special code for that, but on my laptop I only see the X server under the "clients" debugfs file. Yes we have special code in i915 for this. Part of this series we are discussing here. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. Completely agree. The key point is you either need to have all references to an open fd, or at least track whoever last used that fd. At least the last time I looked even the fs layer didn't know which fd is open by which process. So there wasn't really any alternative to the lsof approach. I asked you about the use case you have in mind which you did not answer. Otherwise I don't understand when do you need to walk all files. What information you want to get? For the use case of knowing which DRM file is using how much GPU time on engine X we do not need to walk all open files either with my sysfs approach or the proc approach from Chris. (In the former case we optionally aggregate by PID at presentation time, and in the latter case aggregation is implicit.) Regards, Tvrtko
Re: [PATCH 0/7] Per client engine busyness
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. Well I just double checked and that is not correct. Could be that i915 has some special code for that, but on my laptop I only see the X server under the "clients" debugfs file. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. Completely agree. The key point is you either need to have all references to an open fd, or at least track whoever last used that fd. At least the last time I looked even the fs layer didn't know which fd is open by which process. So there wasn't really any alternative to the lsof approach. Regards, Christian. So even with sysfs aid for discovery you are back to just going over all files again. For what use case? To enable GPU usage in top we can do much better than iterate over all open files in the system. We can start with a process if going with the /proc proposal, or with the opened DRM file directly with the sysfs proposal. Both are significantly fewer than total number of open files across all processes. Regards, Tvrtko
[PATCH][V2][next] drm/vmwgfx: Fix memory allocation check and a leak of object fifo
From: Colin Ian King
The allocation of fifo is lacking an allocation failure check, so
fix this by adding one.
In the case where fifo->static_buffer fails to be allocated the
error return path neglects to kfree the fifo object. Fix this by
adding in the missing kfree.
Kudos to Dan Carpenter for spotting the missing kzalloc failure
check.
Addresses-Coverity: ("Resource leak")
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Colin Ian King
---
V2: Add missing allocation failure check
Update $SUBJECT to reflect this extra change
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
index 027d7d504e78..d9acd2f3f673 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
@@ -105,10 +105,14 @@ struct vmw_fifo_state *vmw_fifo_create(struct vmw_private
*dev_priv)
return NULL;
fifo = kzalloc(sizeof(*fifo), GFP_KERNEL);
+ if (!fifo)
+ return ERR_PTR(-ENOMEM);
fifo->static_buffer_size = VMWGFX_FIFO_STATIC_SIZE;
fifo->static_buffer = vmalloc(fifo->static_buffer_size);
- if (unlikely(fifo->static_buffer == NULL))
+ if (unlikely(fifo->static_buffer == NULL)) {
+ kfree(fifo);
return ERR_PTR(-ENOMEM);
+ }
fifo->dynamic_buffer = NULL;
fifo->reserved_size = 0;
--
2.30.2
Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
On 13/05/2021 16:55, Ezequiel Garcia wrote: > Hi Neil, > > On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote: >> >> Hi, >> >> On 21/04/2021 07:28, Nicolas Boichat wrote: >>> Hi! >>> >>> This is just a rebase of the v11, untested (but it seems like >>> Neil Armstrong recently tested it), with small changes in >>> binding and dts. v11 cover follows: >>> >>> Follow-up on the v5 [1], things have gotten significantly >>> better in the last year, thanks to the efforts on Bifrost >>> support by the Collabora team (and probably others I'm not >>> aware of). >>> >>> I've been testing this series on a MT8183/kukui device, with a >>> chromeos-5.10 kernel [2], and got basic Chromium OS UI up with >>> mesa 20.3.2 (lots of artifacts though). >>> >>> devfreq is currently not supported, as we'll need: >>> - Clock core support for switching the GPU core clock (see 2/4). >>> - Platform-specific handling of the 2-regulator (see 3/4). >>> >>> Since the latter is easy to detect, patch 3/4 just disables >>> devfreq if the more than one regulator is specified in the >>> compatible matching table. >>> >>> [1] >>> https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ >>> [2] https://crrev.com/c/2608070 >>> >>> Changes in v13: >>> - devfreq: Fix conflict resolution mistake when rebasing, didn't >>>even compile. Oops. >>> >>> Changes in v12: >>> - binding: Fix min/maxItems logic (Rob Herring) >>> - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). >>> >>> Changes in v11: >>> - binding: power-domain-names not power-domainS-names >>> - mt8183*.dts: remove incorrect supply-names >>> >>> Changes in v10: >>> - Fix the binding to make sure sram-supply property can be provided. >>> >>> Changes in v9: >>> - Explain why devfreq needs to be disabled for GPUs with >1 >>>regulators. >>> >>> Changes in v8: >>> - Use DRM_DEV_INFO instead of ERROR >>> >>> Changes in v7: >>> - Fix GPU ID in commit message >>> - Fix GPU ID in commit message >>> >>> Changes in v6: >>> - Rebased, actually tested with recent mesa driver. >>> - Add gpu regulators to kukui dtsi as well. >>> - Power domains are now attached to spm, not scpsys >>> - Drop R-B. >>> - devfreq: New change >>> - Context conflicts, reflow the code. >>> - Use ARRAY_SIZE for power domains too. >>> >>> Changes in v5: >>> - Rename "2d" power domain to "core2" >>> - Rename "2d" power domain to "core2" (keep R-B again). >>> - Change power domain name from 2d to core2. >>> >>> Changes in v4: >>> - Add power-domain-names description >>>(kept Alyssa's reviewed-by as the change is minor) >>> - Add power-domain-names to describe the 3 domains. >>>(kept Alyssa's reviewed-by as the change is minor) >>> - Add power domain names. >>> >>> Changes in v3: >>> - Match mt8183-mali instead of bifrost, as we require special >>>handling for the 2 regulators and 3 power domains. >>> >>> Changes in v2: >>> - Use sram instead of mali_sram as SRAM supply name. >>> - Rename mali@ to gpu@. >>> >>> Nicolas Boichat (4): >>> dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 >>> arm64: dts: mt8183: Add node for the Mali GPU >>> drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 >>> drm/panfrost: Add mt8183-mali compatible string >>> >>> .../bindings/gpu/arm,mali-bifrost.yaml| 30 - >>> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + >>> .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + >>> .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + >>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ >>> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ >>> drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ >>> 7 files changed, 168 insertions(+), 1 deletion(-) >>> >> >> Seems this version is ready to be applied if we get a review on the DT ? >> >> Mathias ? could you have a look ? >> > > Given Rob has Acked the DT bindings, I think it's OK to apply patches > 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes. > > My two unsolicited cents :-) Yeah sure, is there a panfrost maintainer in the room ? I can apply them if you ack me. Neil > > Ezequiel >
Re: [PATCH 0/7] Per client engine busyness
On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. So even with sysfs aid for discovery you are back to just going over all files again. For what use case? To enable GPU usage in top we can do much better than iterate over all open files in the system. We can start with a process if going with the /proc proposal, or with the opened DRM file directly with the sysfs proposal. Both are significantly fewer than total number of open files across all processes. Regards, Tvrtko
Re: [PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRAM BAR is enough.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f7cca25c0fa0..73cbc3c7453f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3666,6 +3666,25 @@ int amdgpu_device_init(struct amdgpu_device *adev,
return r;
}
+static void amdgpu_device_unmap_mmio(struct amdgpu_device *adev)
+{
+ /* Clear all CPU mappings pointing to this device */
+ unmap_mapping_range(adev->ddev.anon_inode->i_mapping, 0, 0, 1);
+
+ /* Unmap all mapped bars - Doorbell, registers and VRAM */
+ amdgpu_device_doorbell_fini(adev);
+
+ iounmap(adev->rmmio);
+ adev->rmmio = NULL;
+ if (adev->mman.aper_base_kaddr)
+ iounmap(adev->mman.aper_base_kaddr);
+ adev->mman.aper_base_kaddr = NULL;
+
+ /* Memory manager related */
+ arch_phys_wc_del(adev->gmc.vram_mtrr);
+ arch_io_free_memtype_wc(adev->gmc.aper_base, adev->gmc.aper_size);
+}
+
/**
* amdgpu_device_fini - tear down the driver
*
@@ -3712,6 +3731,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
amdgpu_device_ip_fini_early(adev);
amdgpu_gart_dummy_page_fini(adev);
+
+ amdgpu_device_unmap_mmio(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
@@ -3739,9 +3760,6 @@ void amdgpu_device_fini_sw(struct amdgpu_device *adev)
}
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
vga_client_register(adev->pdev, NULL, NULL, NULL);
- iounmap(adev->rmmio);
- adev->rmmio = NULL;
- amdgpu_device_doorbell_fini(adev);
if (IS_ENABLED(CONFIG_PERF_EVENTS))
amdgpu_pmu_fini(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 0adffcace326..882fb49f3c41 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -533,6 +533,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
return -ENOMEM;
drm_gem_private_object_init(adev_to_drm(adev), >tbo.base, size);
INIT_LIST_HEAD(>shadow_list);
+
bo->vm_bo = NULL;
bo->preferred_domains = bp->preferred_domain ? bp->preferred_domain :
bp->domain;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0d54e70278ca..58ad2fecc9e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1841,10 +1841,6 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
amdgpu_bo_free_kernel(>mman.discovery_memory, NULL, NULL);
amdgpu_ttm_fw_reserve_vram_fini(adev);
- if (adev->mman.aper_base_kaddr)
- iounmap(adev->mman.aper_base_kaddr);
- adev->mman.aper_base_kaddr = NULL;
-
amdgpu_vram_mgr_fini(adev);
amdgpu_gtt_mgr_fini(adev);
ttm_range_man_fini(>mman.bdev, AMDGPU_PL_GDS);
Re: [PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
If removing while commands in flight you cannot wait to flush the
HW fences on a ring since the device is gone.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 1ffb36bd0b19..fa03702ecbfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_trace.h"
@@ -525,8 +526,7 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
*/
void amdgpu_fence_driver_fini_hw(struct amdgpu_device *adev)
{
- unsigned i, j;
- int r;
+ int i, r;
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -535,11 +535,15 @@ void amdgpu_fence_driver_fini_hw(struct amdgpu_device
*adev)
continue;
if (!ring->no_scheduler)
drm_sched_fini(>sched);
- r = amdgpu_fence_wait_empty(ring);
- if (r) {
- /* no need to trigger GPU reset as we are unloading */
+ /* You can't wait for HW to signal if it's gone */
+ if (!drm_dev_is_unplugged(>ddev))
+ r = amdgpu_fence_wait_empty(ring);
+ else
+ r = -ENODEV;
+ /* no need to trigger GPU reset as we are unloading */
+ if (r)
amdgpu_fence_driver_force_completion(ring);
- }
+
if (ring->fence_drv.irq_src)
amdgpu_irq_put(adev, ring->fence_drv.irq_src,
ring->fence_drv.irq_type);
Re: [PATCH v7 05/16] drm/amdgpu: Handle IOMMU enabled case.
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
v7:
Drop amdgpu_gart_fini
In amdgpu_ih_ring_fini do uncinditional check (!ih->ring)
to avoid freeing uniniitalized rings.
Call amdgpu_ih_ring_fini unconditionally.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 5 +
drivers/gpu/drm/amd/amdgpu/cik_ih.c| 1 -
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/iceland_ih.c| 1 -
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/si_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4
18 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 18598eda18f6..a0bff4713672 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3256,7 +3256,6 @@ static const struct attribute *amdgpu_dev_attributes[] = {
NULL
};
-
/**
* amdgpu_device_init - initialize the driver
*
@@ -3698,12 +3697,13 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
amdgpu_ucode_sysfs_fini(adev);
sysfs_remove_files(>dev->kobj, amdgpu_dev_attributes);
-
amdgpu_fbdev_fini(adev);
amdgpu_irq_fini_hw(adev);
amdgpu_device_ip_fini_early(adev);
+
+ amdgpu_gart_dummy_page_fini(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index c5a9a4fb10d2..6460cf723f0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct amdgpu_device
*adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
@@ -365,15 +365,3 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
return 0;
}
-
-/**
- * amdgpu_gart_fini - tear down the driver info for managing the gart
- *
- * @adev: amdgpu_device pointer
- *
- * Tear down the gart driver info and free the dummy page (all asics).
- */
-void amdgpu_gart_fini(struct amdgpu_device *adev)
-{
- amdgpu_gart_dummy_page_fini(adev);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
index a25fe97b0196..030b9d4c736a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
@@ -57,7 +57,7 @@ void amdgpu_gart_table_vram_free(struct amdgpu_device *adev);
int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev);
void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev);
int amdgpu_gart_init(struct amdgpu_device *adev);
-void amdgpu_gart_fini(struct amdgpu_device *adev);
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev);
int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
int pages);
int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index faaa6aa2faaf..433469ace6f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -115,9 +115,11 @@ int amdgpu_ih_ring_init(struct amdgpu_device *adev, struct
amdgpu_ih_ring *ih,
*/
void amdgpu_ih_ring_fini(struct amdgpu_device *adev, struct amdgpu_ih_ring
*ih)
{
+
+ if (!ih->ring)
+ return;
+
if (ih->use_bus_addr) {
- if (!ih->ring)
- return;
/* add 8 bytes for the rptr/wptr shadows and
* add them to the end of the ring allocation.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 233b64dab94b..32ce0e679dc7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -361,6 +361,11 @@ void amdgpu_irq_fini_hw(struct
Re: [PATCH 1/2] drm: Fix dirtyfb stalls
On Fri, May 14, 2021 at 12:54 AM Pekka Paalanen wrote: > > On Wed, 12 May 2021 07:57:26 -0700 > Rob Clark wrote: > > > On Wed, May 12, 2021 at 1:23 AM Pekka Paalanen wrote: > > > > > > On Tue, 11 May 2021 18:44:17 +0200 > > > Daniel Vetter wrote: > > > > > > > On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote: > > > > > On Mon, May 10, 2021 at 10:44 AM Daniel Vetter > > > > > wrote: > > > > > > > > > > > > On Mon, May 10, 2021 at 6:51 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > On Mon, May 10, 2021 at 9:14 AM Daniel Vetter > > > > > > > wrote: > > > > > > > > > > > > > > > > On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote: > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > > > drm_atomic_helper_dirtyfb() will end up stalling for vblank > > > > > > > > > on "video > > > > > > > > > mode" type displays, which is pointless and unnecessary. Add > > > > > > > > > an > > > > > > > > > optional helper vfunc to determine if a plane is attached to > > > > > > > > > a CRTC > > > > > > > > > that actually needs dirtyfb, and skip over them. > > > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > ... > > > > > > > > But we could re-work drm_framebuffer_funcs::dirty to operate on a > > > > > > > per-crtc basis and hoist the loop and check if dirtyfb is needed > > > > > > > out > > > > > > > of drm_atomic_helper_dirtyfb() > > > > > > > > > > > > That's still using information that userspace doesn't have, which > > > > > > is a > > > > > > bit irky. We might as well go with your thing here then. > > > > > > > > > > arguably, this is something we should expose to userspace.. for DSI > > > > > command-mode panels, you probably want to make a different decision > > > > > with regard to how many buffers in your flip-chain.. > > > > > > > > > > Possibly we should add/remove the fb_damage_clips property depending > > > > > on the display type (ie. video/pull vs cmd/push mode)? > > > > > > > > I'm not sure whether atomic actually needs this exposed: > > > > - clients will do full flips for every frame anyway, I've not heard of > > > > anyone seriously doing frontbuffer rendering. > > > > > > That may or may not be changing, depending on whether the DRM drivers > > > will actually support tearing flips. There has been a huge amount of > > > debate for needing tearing for Wayland [1], and while I haven't really > > > joined that discussion, using front-buffer rendering (blits) to work > > > around the driver inability to flip-tear might be something some people > > > will want. > > > > jfwiw, there is a lot of hw that just can't do tearing pageflips.. I > > think this probably includes most arm hw. What is done instead is to > > skip the pageflip and render directly to the front-buffer. > > > > EGL_KHR_mutable_render_buffer is a thing you might be interested in.. > > it is wired up for android on i965 and there is a WIP MR[1] for > > mesa/st (gallium): > > > > Possibly it could be useful to add support for platform_wayland? > > > > [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10685 > > Thanks Rob, that's interesting. > > I would like to say that EGL Wayland platform cannot and has no reason > to support frontbuffer rendering in Wayland clients, because the > compositor may be reading the current client frontbuffer at any time, > including *not reading it again* until another update is posted via > Wayland. So if a Wayland client is doing frontbuffer rendering, then I > would expect it to be very likely that the window might almost never > show a "good" picture, meaning that it is literally just the > half-rendered frame after the current one with continuously updating > clients. > > That is because a Wayland client doing frontbuffer rendering is > completely unrelated to the Wayland compositor putting the client > buffer on scanout. > > Frontbuffer rendering used by a Wayland compositor would be used for > fallback tearing updates, where the rendering is roughly just a blit > from a client buffer. By definition, it means blit instead of scanout > from client buffers, so the performance/power hit is going to be... > let's say observable. > > If a Wayland client did frontbuffer rendering, and then it used a > shadow buffer of its own to minimise the level of garbage on screen by > doing only blits into the frontbuffer, that would again be a blit. And > then the compositor might be doing another blit because it doesn't know > the client is doing frontbuffer rendering which would theoretically > allow the compositor to scan out the client buffer. > > There emerges the need for a Wayland extension for clients to be > telling the compositor explicitly that they are going to be doing > frontbuffer rendering now, it is ok to put the client buffer on scanout > even if you want to do tearing updates on hardware that cannot > tear-flip. > > However, knowing that a client buffer is good for scanout is not > sufficient for scanout in a compositor,
Re: [PATCH][next] drm/vmwgfx: Fix memory leak of object fifo on error return
On 14/05/2021 15:30, Dan Carpenter wrote:
> On Wed, May 12, 2021 at 08:56:09PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> In the case where fifo->static_buffer fails to be allocated the
>> error return path neglects to kfree the fifo object. Fix this by
>> adding in the missing kfree.
>>
>> Addresses-Coverity: ("Resource leak")
>> Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> index 027d7d504e78..e5fa210f589e 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> @@ -107,8 +107,10 @@ struct vmw_fifo_state *vmw_fifo_create(struct
>> vmw_private *dev_priv)
>> fifo = kzalloc(sizeof(*fifo), GFP_KERNEL);
>
> This needs an:
>
> if (!fifo)
> return -ENOMEM;
Doh, I completely missed that. I'll send a V2. Thanks Dan.
>
>> fifo->static_buffer_size = VMWGFX_FIFO_STATIC_SIZE;
>> fifo->static_buffer = vmalloc(fifo->static_buffer_size);
>> -if (unlikely(fifo->static_buffer == NULL))
>> +if (unlikely(fifo->static_buffer == NULL)) {
>> +kfree(fifo);
>> return ERR_PTR(-ENOMEM);
>> +}
>
> regards,
> dan carpenter
>
Re: [PATCH][next] drm/vmwgfx: Fix memory leak of object fifo on error return
On Wed, May 12, 2021 at 08:56:09PM +0100, Colin King wrote:
> From: Colin Ian King
>
> In the case where fifo->static_buffer fails to be allocated the
> error return path neglects to kfree the fifo object. Fix this by
> adding in the missing kfree.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> index 027d7d504e78..e5fa210f589e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> @@ -107,8 +107,10 @@ struct vmw_fifo_state *vmw_fifo_create(struct
> vmw_private *dev_priv)
> fifo = kzalloc(sizeof(*fifo), GFP_KERNEL);
This needs an:
if (!fifo)
return -ENOMEM;
> fifo->static_buffer_size = VMWGFX_FIFO_STATIC_SIZE;
> fifo->static_buffer = vmalloc(fifo->static_buffer_size);
> - if (unlikely(fifo->static_buffer == NULL))
> + if (unlikely(fifo->static_buffer == NULL)) {
> + kfree(fifo);
> return ERR_PTR(-ENOMEM);
> + }
regards,
dan carpenter
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
Em Fri, 14 May 2021 12:08:36 +0100
Edward Cree escreveu:
> For anyone who doesn't know about it: X has this wonderful thing called
> the Compose key[1]. For instance, type ⎄--- to get —, or ⎄<" for “.
> Much more mnemonic than Unicode codepoints; and you can extend it with
> user-defined sequences in your ~/.XCompose file.
Good tip. I haven't use composite for years, as US-intl with dead keys is
enough for 99.999% of my needs.
Btw, at least on Fedora with Mate, Composite is disabled by default. It has
to be enabled first using the same tool that allows changing the Keyboard
layout[1].
Yet, typing an EN DASH for example, would be "--.", with is 4
keystrokes instead of just two ('--'). It means twice the effort ;-)
[1] KDE, GNome, Mate, ... have different ways to enable it and to
select what key would be considered :
https://dry.sailingissues.com/us-international-keyboard-layout.html
https://help.ubuntu.com/community/ComposeKey
Thanks,
Mauro
Re: [PATCH v15 2/4] dt-bindings: msm: dsi: add yaml schemas for DSI bindings
On Wed, May 5, 2021 at 11:11 PM wrote: > > On 2021-04-08 20:33, Rob Herring wrote: > > On Mon, Apr 05, 2021 at 04:36:08PM +0530, Krishna Manikandan wrote: > >> Add YAML schema for the device tree bindings for DSI > >> + data-lanes: > >> +$ref: "/schemas/media/video-interfaces.yaml#" > > > > Not how this reference works. Look at other examples. > > > >> +description: | > >> + This describes how the physical DSI data lanes are > >> mapped > >> + to the logical lanes on the given platform. The > >> value contained in > >> + index n describes what physical lane is mapped to > >> the logical lane n > >> + (DATAn, where n lies between 0 and 3). The clock > >> lane position is fixed > >> + and can't be changed. Hence, they aren't a part of > >> the DT bindings. > >> + > >> +items: > >> + - const: 0 > >> + - const: 1 > >> + - const: 2 > >> + - const: 3 > > > > If this is the only possible value, why does it need to be in DT? > Hi Rob, > These are the possible values: > -<0 1 2 3> > -<1 2 3 0> > -<2 3 0 1> > -<3 0 1 2> > -<0 3 2 1> > -<1 0 3 2> > -<2 1 0 3> > -<3 2 1 0> > > Shall I follow the below mentioned approach for defining these values ? > oneOf: >- items: > - const: 0 > - const: 1 > - const: 2 > - const: 3 >- items: > - const: 1 > - const: 2 > - const: 3 > - const: 0 >- items: > - const: 2 > - const: 3 > - const: 0 > - const: 1 >- items: > - const: 3 > - const: 0 > - const: 1 > - const: 2 >- items: > - const: 0 > - const: 3 > - const: 2 > - const: 1 >- items: > - const: 1 > - const: 0 > - const: 3 > - const: 2 >- items: > - const: 2 > - const: 1 > - const: 0 > - const: 3 >- items: > - const: 3 > - const: 2 > - const: 1 > - const: 0 That's too verbose. maxItems: 4 minItems: 4 (or is less supported?) items: enum: [ 0, 1, 2, 3 ]
[bug report] drm: remove usage of drm_pci_alloc/free
Hello Joseph Kogut,
The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free"
from Apr 22, 2021, leads to the following static checker warning:
drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
warn: inconsistent returns '>struct_mutex'.
Locked on : 988
Unlocked on: 938,944,951,959,973,1005,1042,1060,1090
drivers/gpu/drm/drm_bufs.c
965 temp_pagelist = kmalloc_array(dma->page_count + (count <<
page_order),
966sizeof(*dma->pagelist),
967GFP_KERNEL);
968 if (!temp_pagelist) {
969 kfree(entry->buflist);
970 kfree(entry->seglist);
971 mutex_unlock(>struct_mutex);
972 atomic_dec(>buf_alloc);
973 return -ENOMEM;
There is a bunch of clean up happenning on the existing returns.
974 }
975 memcpy(temp_pagelist,
976 dma->pagelist, dma->page_count * sizeof(*dma->pagelist));
977 DRM_DEBUG("pagelist: %d entries\n",
978dma->page_count + (count << page_order));
979
980 entry->buf_size = size;
981 entry->page_order = page_order;
982 byte_count = 0;
983 page_count = 0;
984
985 while (entry->buf_count < count) {
986 dmah = kmalloc(sizeof(drm_dma_handle_t), GFP_KERNEL);
987 if (!dmah)
988 return -ENOMEM;
This new return has no clean up. We a mutex_unlock(>struct_mutex).
989
990 dmah->size = total;
991 dmah->vaddr = dma_alloc_coherent(dev->dev,
992 dmah->size,
993 >busaddr,
994 GFP_KERNEL);
995 if (!dmah->vaddr) {
996 kfree(dmah);
997
998 /* Set count correctly so we free the proper
amount. */
999 entry->buf_count = count;
1000 entry->seg_count = count;
1001 drm_cleanup_buf_error(dev, entry);
1002 kfree(temp_pagelist);
1003 mutex_unlock(>struct_mutex);
1004 atomic_dec(>buf_alloc);
1005 return -ENOMEM;
1006 }
1007 entry->seglist[entry->seg_count++] = dmah;
1008 for (i = 0; i < (1 << page_order); i++) {
1009 DRM_DEBUG("page %d @ 0x%08lx\n",
regards,
dan carpenter
[PATCH] drm/tegra: fix 32-bit DMA address calculation
From: Arnd Bergmann
gcc points out an invalid bit shift operation on 32-bit architectures
with 64-bit dma_addr_t:
drivers/gpu/drm/tegra/hub.c: In function 'tegra_shared_plane_atomic_update':
include/vdso/bits.h:7:40: error: left shift count >= width of type
[-Werror=shift-count-overflow]
7 | #define BIT(nr) (UL(1) << (nr))
|^~
drivers/gpu/drm/tegra/hub.c:513:25: note: in expansion of macro 'BIT'
513 | base |= BIT(39);
| ^~~
Use the correct BIT_ULL() macro to always generate a 64-bit mask.
Fixes: 7b6f846785f4 ("drm/tegra: Support sector layout on Tegra194")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/tegra/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 79bff8b48271..bfae8a02f55b 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -510,7 +510,7 @@ static void tegra_shared_plane_atomic_update(struct
drm_plane *plane,
* dGPU sector layout.
*/
if (tegra_plane_state->tiling.sector_layout ==
TEGRA_BO_SECTOR_LAYOUT_GPU)
- base |= BIT(39);
+ base |= BIT_ULL(39);
#endif
tegra_plane_writel(p, tegra_plane_state->format, DC_WIN_COLOR_DEPTH);
--
2.29.2
Re: [PATCH 0/7] Per client engine busyness
David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. So even with sysfs aid for discovery you are back to just going over all files again. Regards, Christian. Am 14.05.21 um 15:42 schrieb Tvrtko Ursulin: On 14/05/2021 09:04, Christian König wrote: Well in my opinion exposing it through fdinfo turned out to be a really clean approach. It describes exactly the per file descriptor information we need. Yeah fdinfo certainly is mostly simple and neat. I say mostly because main problem I see with it is discoverability. Alex commented in another sub-thread - "If you know the process, you can look it up in procfs." - so that's fine for introspection but a bit challenging for a top(1) like tool. David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Top level hierarchy is under /sys/class/drm/card0/clients/ and each opened drm fd gets a directory in there. Process data I expose there are the name and pid, but these are for convenience, not as a primary information. But yes, I agree this part of the approach is definitely questionable. (As a side note, I am not sure if I could put a symlink to proc in there. I think sysfs and symlinks did not really work.) Another data point is that this "client root" we think would be useful for adding other stuff in the future. For instance per client debug log stream is occasionally talked about. Making that device driver independent is potentially useful as well. Alternative to my sysfs approach, the idea of exposing this in proc was floated by Chris in this series https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F86692%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C69e215ff2b434ba36ecc08d916de1754%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637565965394961215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JsARknf2q%2FwtGfgLM6ZUOSkaivV%2B6yakpqYh%2B6yQlEc%3Dreserved=0. That would be generic enough so any GPU vendor can slot in, and common enough that GPU agnostic tools should be able to use it. Modulo some discussion around naming the "channels" (GPU engines) or not. It wouldn't be able to support things like the before mentioned per client debug log stream but I guess that's not the most important thing. Most important would be allowing GPU usage to be wired to top(1) like tools which is probably even overdue given the modern computing landscape. Would you guys be interested to give a more detailed look over both proposals and see if any would interest you? Regards, Tvrtko Regards, Christian. Am 14.05.21 um 09:22 schrieb Nieto, David M: [AMD Official Use Only - Internal Distribution Only] We had entertained the idea of exposing the processes as sysfs nodes as you proposed, but we had concerns about exposing process info in there, especially since /proc already exists for that purpose. I think if you were to follow that approach, we could have tools like top that support exposing GPU engine usage. *From:* Alex Deucher *Sent:* Thursday, May 13, 2021 10:58 PM *To:* Tvrtko Ursulin ; Nieto, David M ; Koenig, Christian *Cc:* Intel Graphics Development ; Maling list - DRI developers ; Daniel Vetter *Subject:* Re: [PATCH 0/7] Per client engine busyness + David, Christian On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin wrote: > > > Hi, > > On 13/05/2021 16:48, Alex Deucher wrote: > > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin > > wrote: > >> > >> From: Tvrtko Ursulin > >> > >> Resurrect of the previosuly merged per client engine busyness patches. In a > >> nutshell it enables intel_gpu_top to be more top(1) like useful and show not > >> only physical GPU engine usage but per process view as well. > >> > >> Example screen capture: > >> > >> intel-gpu-top - 906/ 955 MHz; 0% RC6; 5.30 Watts; 933 irqs/s > >> > >> IMC reads: 4414 MiB/s > >> IMC writes: 3805 MiB/s > >> > >> ENGINE BUSY MI_SEMA MI_WAIT > >> Render/3D/0 93.46% |▋ | 0% 0%
Re: [PATCH 0/7] Per client engine busyness
On 14/05/2021 09:04, Christian König wrote: Well in my opinion exposing it through fdinfo turned out to be a really clean approach. It describes exactly the per file descriptor information we need. Yeah fdinfo certainly is mostly simple and neat. I say mostly because main problem I see with it is discoverability. Alex commented in another sub-thread - "If you know the process, you can look it up in procfs." - so that's fine for introspection but a bit challenging for a top(1) like tool. David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Top level hierarchy is under /sys/class/drm/card0/clients/ and each opened drm fd gets a directory in there. Process data I expose there are the name and pid, but these are for convenience, not as a primary information. But yes, I agree this part of the approach is definitely questionable. (As a side note, I am not sure if I could put a symlink to proc in there. I think sysfs and symlinks did not really work.) Another data point is that this "client root" we think would be useful for adding other stuff in the future. For instance per client debug log stream is occasionally talked about. Making that device driver independent is potentially useful as well. Alternative to my sysfs approach, the idea of exposing this in proc was floated by Chris in this series https://patchwork.freedesktop.org/series/86692/. That would be generic enough so any GPU vendor can slot in, and common enough that GPU agnostic tools should be able to use it. Modulo some discussion around naming the "channels" (GPU engines) or not. It wouldn't be able to support things like the before mentioned per client debug log stream but I guess that's not the most important thing. Most important would be allowing GPU usage to be wired to top(1) like tools which is probably even overdue given the modern computing landscape. Would you guys be interested to give a more detailed look over both proposals and see if any would interest you? Regards, Tvrtko Regards, Christian. Am 14.05.21 um 09:22 schrieb Nieto, David M: [AMD Official Use Only - Internal Distribution Only] We had entertained the idea of exposing the processes as sysfs nodes as you proposed, but we had concerns about exposing process info in there, especially since /proc already exists for that purpose. I think if you were to follow that approach, we could have tools like top that support exposing GPU engine usage. *From:* Alex Deucher *Sent:* Thursday, May 13, 2021 10:58 PM *To:* Tvrtko Ursulin ; Nieto, David M ; Koenig, Christian *Cc:* Intel Graphics Development ; Maling list - DRI developers ; Daniel Vetter *Subject:* Re: [PATCH 0/7] Per client engine busyness + David, Christian On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin wrote: > > > Hi, > > On 13/05/2021 16:48, Alex Deucher wrote: > > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin > > wrote: > >> > >> From: Tvrtko Ursulin > >> > >> Resurrect of the previosuly merged per client engine busyness patches. In a > >> nutshell it enables intel_gpu_top to be more top(1) like useful and show not > >> only physical GPU engine usage but per process view as well. > >> > >> Example screen capture: > >> > >> intel-gpu-top - 906/ 955 MHz; 0% RC6; 5.30 Watts; 933 irqs/s > >> > >> IMC reads: 4414 MiB/s > >> IMC writes: 3805 MiB/s > >> > >> ENGINE BUSY MI_SEMA MI_WAIT > >> Render/3D/0 93.46% |▋ | 0% 0% > >> Blitter/0 0.00% | | 0% 0% > >> Video/0 0.00% | | 0% 0% > >> VideoEnhance/0 0.00% | | 0% 0% > >> > >> PID NAME Render/3D Blitter Video VideoEnhance > >> 2733 neverball |██▌ || || || | > >> 2047 Xorg |███▊ || || || | > >> 2737 glxgears |█▍ || || || | > >> 2128 xfwm4 | || || || | > >> 2047 Xorg | || || || | > >> > >> > >> Internally we track time spent on engines for each struct intel_context, both > >> for current and past contexts belonging to each open DRM file. > >> > >> This can serve as a building block for several features from the wanted list: > >> smarter scheduler decisions, getrusage(2)-like per-GEM-context functionality >
Re: [PATCH v2] drm/i915/gem: Pin the L-shape quirked object as unshrinkable
On Thu, May 13, 2021 at 01:07:56PM +0100, Matthew Auld wrote:
> From: Chris Wilson
>
> When instantiating a tiled object on an L-shaped memory machine, we mark
> the object as unshrinkable to prevent the shrinker from trying to swap
> out the pages. We have to do this as we do not know the swizzling on the
> individual pages, and so the data will be scrambled across swap out/in.
>
> Not only do we need to move the object off the shrinker list, we need to
> mark the object with shrink_pin so that the counter is consistent across
> calls to madvise.
>
> v2: in the madvise ioctl we need to check if the object is currently
> shrinkable/purgeable, not if the object type supports shrinking
>
> Fixes: 0175969e489a ("drm/i915/gem: Use shrinkable status for unknown swizzle
> quirks")
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3293
> Reported-by: Ville Syrjälä
> Signed-off-by: Chris Wilson
> Signed-off-by: Matthew Auld
This one seems to fare better than v1.
Tested-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 ++
> drivers/gpu/drm/i915/i915_gem.c | 11 +--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index aed8a37ccdc9..7361971c177d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -63,6 +63,8 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
> *obj,
> i915->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
> GEM_BUG_ON(i915_gem_object_has_tiling_quirk(obj));
> i915_gem_object_set_tiling_quirk(obj);
> + GEM_BUG_ON(!list_empty(>mm.link));
> + atomic_inc(>mm.shrink_pin);
> shrinkable = false;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d0018c5f88bd..cffd7f4f87dc 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1009,12 +1009,11 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
> *data,
> obj->mm.madv = args->madv;
>
> if (i915_gem_object_has_pages(obj)) {
> - struct list_head *list;
> + unsigned long flags;
>
> - if (i915_gem_object_is_shrinkable(obj)) {
> - unsigned long flags;
> -
> - spin_lock_irqsave(>mm.obj_lock, flags);
> + spin_lock_irqsave(>mm.obj_lock, flags);
> + if (!list_empty(>mm.link)) {
> + struct list_head *list;
>
> if (obj->mm.madv != I915_MADV_WILLNEED)
> list = >mm.purge_list;
> @@ -1022,8 +1021,8 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
> *data,
> list = >mm.shrink_list;
> list_move_tail(>mm.link, list);
>
> - spin_unlock_irqrestore(>mm.obj_lock, flags);
> }
> + spin_unlock_irqrestore(>mm.obj_lock, flags);
> }
>
> /* if the object is no longer attached, discard its backing storage */
> --
> 2.26.3
--
Ville Syrjälä
Intel
Re: [PATCH v5 4/6] drm/sprd: add Unisoc's drm display controller driver
Maxime Ripard 于2021年4月30日周五 下午5:22写道： > > On Sun, Apr 25, 2021 at 08:36:05PM +0800, Kevin Tang wrote: > > Adds DPU(Display Processor Unit) support for the Unisoc's display > > subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > > > v2: > > - Use drm_xxx to replace all DRM_XXX. > > - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. > > > > v3: > > - Remove dpu_layer stuff layer and commit layers by aotmic_update > > > > v4: > > - Use drmm_helpers to allocate crtc and planes. > > - Move rotation enum definitions to crtc layer reg bitfields. > > - Move allocate crtc and planes to bind function. > > > > v5: > > - Fix the checkpatch warnings. > > - Use mode_set_nofb instead of mode_valid callback. > > - Follow the OF-Graph bindings, use of_graph_get_port_by_id > > instead of of_parse_phandle. > > - Use zpos to represent the layer position. > > - Rebase to last drm misc branch. > > > > Cc: Orson Zhai > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > --- > > drivers/gpu/drm/sprd/Kconfig| 1 + > > drivers/gpu/drm/sprd/Makefile | 3 +- > > drivers/gpu/drm/sprd/sprd_dpu.c | 939 > > drivers/gpu/drm/sprd/sprd_dpu.h | 109 > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > 6 files changed, 1054 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > > index 726c3e76d..37762c333 100644 > > --- a/drivers/gpu/drm/sprd/Kconfig > > +++ b/drivers/gpu/drm/sprd/Kconfig > > @@ -5,6 +5,7 @@ config DRM_SPRD > > select DRM_GEM_CMA_HELPER > > select DRM_KMS_CMA_HELPER > > select DRM_KMS_HELPER > > + select VIDEOMODE_HELPERS > > help > > Choose this option if you have a Unisoc chipset. > > If M is selected the module will be called sprd_drm. > > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile > > index 9850f00b8..ab12b95e6 100644 > > --- a/drivers/gpu/drm/sprd/Makefile > > +++ b/drivers/gpu/drm/sprd/Makefile > > @@ -1,3 +1,4 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -obj-y := sprd_drm.o > > +obj-y := sprd_drm.o \ > > + sprd_dpu.o > > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c > > b/drivers/gpu/drm/sprd/sprd_dpu.c > > new file mode 100644 > > index 0..e74c3dbb3 > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c > > @@ -0,0 +1,939 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2020 Unisoc Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "sprd_drm.h" > > +#include "sprd_dpu.h" > > + > > +/* Global control registers */ > > +#define REG_DPU_CTRL 0x04 > > +#define REG_DPU_CFG0 0x08 > > +#define REG_PANEL_SIZE 0x20 > > +#define REG_BLEND_SIZE 0x24 > > +#define REG_BG_COLOR 0x2C > > + > > +/* Layer0 control registers */ > > +#define REG_LAY_BASE_ADDR0 0x30 > > +#define REG_LAY_BASE_ADDR1 0x34 > > +#define REG_LAY_BASE_ADDR2 0x38 > > +#define REG_LAY_CTRL 0x40 > > +#define REG_LAY_SIZE 0x44 > > +#define REG_LAY_PITCH0x48 > > +#define REG_LAY_POS 0x4C > > +#define REG_LAY_ALPHA0x50 > > +#define REG_LAY_CROP_START 0x5C > > + > > +/* Interrupt control registers */ > > +#define REG_DPU_INT_EN 0x1E0 > > +#define REG_DPU_INT_CLR 0x1E4 > > +#define REG_DPU_INT_STS 0x1E8 > > + > > +/* DPI control registers */ > > +#define REG_DPI_CTRL 0x1F0 > > +#define REG_DPI_H_TIMING 0x1F4 > > +#define REG_DPI_V_TIMING 0x1F8 > > + > > +/* MMU control registers */ > > +#define REG_MMU_EN 0x800 > > +#define REG_MMU_VPN_RANGE0x80C > > +#define REG_MMU_VAOR_ADDR_RD 0x818 > > +#define REG_MMU_VAOR_ADDR_WR 0x81C > > +#define REG_MMU_INV_ADDR_RD 0x820 > > +#define REG_MMU_INV_ADDR_WR 0x824 > > +#define REG_MMU_PPN1 0x83C > > +#define REG_MMU_RANGE1 0x840 > > +#define REG_MMU_PPN2 0x844 > > +#define REG_MMU_RANGE2 0x848 > > + > > +/* Global control bits */ > > +#define BIT_DPU_RUN BIT(0) > > +#define BIT_DPU_STOP BIT(1) > > +#define BIT_DPU_REG_UPDATE BIT(2) > > +#define BIT_DPU_IF_EDPI BIT(0) > > + > > +/* Layer control bits */ > > +#define BIT_DPU_LAY_EN BIT(0) > > +#define BIT_DPU_LAY_LAYER_ALPHA (0x01 << 2) > > +#define BIT_DPU_LAY_COMBO_ALPHA
Re: linux-next: manual merge of the drm-intel tree with the drm tree
Hi
Am 14.05.21 um 03:53 schrieb Stephen Rothwell:
Hi all,
On Fri, 30 Apr 2021 08:23:21 +1000 Stephen Rothwell
wrote:
On Thu, 18 Mar 2021 12:52:41 +1100 Stephen Rothwell
wrote:
On Wed, 17 Mar 2021 14:08:24 +1100 Stephen Rothwell
wrote:
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_sprite.c
between commit:
92f1d09ca4ed ("drm: Switch to %p4cc format modifier")
from the drm tree and commit:
46d12f911821 ("drm/i915: migrate skl planes code new file (v5)")
from the drm-intel tree.
I fixed it up (I used the latter version of the file and applied the
following patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted
for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Wed, 17 Mar 2021 14:05:42 +1100
Subject: [PATCH] merge fix for "drm: Switch to %p4cc format modifier"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 1f335cb09149..45ceff436bf7 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1120,7 +1120,6 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int rotation = plane_state->hw.rotation;
- struct drm_format_name_buf format_name;
if (!fb)
return 0;
@@ -1168,9 +1167,8 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_XVYU12_16161616:
case DRM_FORMAT_XVYU16161616:
drm_dbg_kms(_priv->drm,
- "Unsupported pixel format %s for 90/270!\n",
- drm_get_format_name(fb->format->format,
- _name));
+ "Unsupported pixel format %p4cc for
90/270!\n",
+ >format->format);
return -EINVAL;
default:
break;
--
2.30.0
The above fix up patch now needs to be applied to the drm tree.
I am still applying the above patch, but it applies to Linus' tree now.
I am going to stop applying this. You guys can apply it if you want to
some time.
Sorry, this got lost several times. I've applied your patch to
drm-misc-next now. Thanks a lot.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v1 1/1] video: ssd1307fb: Drop OF dependency
On Fri, Apr 16, 2021 at 05:42:04PM +0300, Andy Shevchenko wrote: > +Cc: Greg. > > Greg, can you pick up this one? > > The subsystem seems orphaned and I see your name in the git history for the > recent submissions against that driver. Now applied, thanks. greg k-h
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
> On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote: >> I do use a lot of UTF-8 here, as I type texts in Portuguese, but I rely >> on the US-intl keyboard settings, that allow me to type as "'a" for á. >> However, there's no shortcut for non-Latin UTF-codes, as far as I know. >> >> So, if would need to type a curly comma on the text editors I normally >> use for development (vim, nano, kate), I would need to cut-and-paste >> it from somewhere For anyone who doesn't know about it: X has this wonderful thing called the Compose key[1]. For instance, type ⎄--- to get —, or ⎄<" for “. Much more mnemonic than Unicode codepoints; and you can extend it with user-defined sequences in your ~/.XCompose file. (I assume Wayland supports all this too, but don't know the details.) On 14/05/2021 10:06, David Woodhouse wrote: > Again, if you want to make specific fixes like removing non-breaking > spaces and byte order marks, with specific reasons, then those make > sense. But it's got very little to do with UTF-8 and how easy it is to > type them. And the excuse you've put in the commit comment for your > patches is utterly bogus. +1 -ed [1] https://en.wikipedia.org/wiki/Compose_key
Re: [PATCH v6 2/5] drm/dp: Allow an early call to register DDC i2c bus
On Fri, 07 May 2021, Lyude Paul wrote:
> On Fri, 2021-05-07 at 17:00 -0500, Bjorn Andersson wrote:
>> On Fri 07 May 16:18 CDT 2021, Lyude Paul wrote:
>>
>> > Adding ville from Intel to also get their take on this.
>> >
>> > In general we've been trying to move DRM to a design where we don't expose
>> > any
>> > devices until everything is ready. That's pretty much the main reason that
>> > we
>> > register things during bridge attach time. Note though that even before
>> > the
>> > DDC bus is registered it should still be usable, just things like
>> > get_device()
>> > won't work.
>> >
>> > This isn't the first time we've run into a problem like the one you're
>> > trying
>> > to solve though, Tegra currently has a similar issue. Something we
>> > discussed
>> > as a possible long-term solution for this was splitting i2c_add_adapter()
>> > into
>> > a minimal initialization function and a registration function. Linux's
>> > device
>> > core already allows for this (device_initialize() and device_add(), which
>> > are
>> > called together when device_register() is called). Would this be a
>> > solution
>> > that might work for you (and even better, would you possibly be willing to
>> > write the patches? :)
>> >
>>
>> It's not enough that the adapter is half-baked, because the bridge's
>> initialization depends on that the panel device is done probing, and the
>> panel driver will only complete its probe if it can find it's resources.
>>
>> So we need a mechanism to fully create the resources exposed by the
>> bridge chip (i2c bus, gpio chip and (soon) a pwm chip), then allow the
>> panel to probe and after that initialize the bridge.
>>
>> We did discuss possible ways to register these resources and then
>> "sleep for a while" before resolving the panel, but what we came up with
>> was definitely suboptimal - and ugly.
>
> Sigh, I'm really starting to wonder if we should reconsider the rules on
> exposing ddc adapters early...
>
> Danvet, Jani, and/or airlied: can I get your take on this?
Granted, I did not study this in detail, but it sounds like we'd need to
be able to add and use an i2c adapter in kernel, before deciding to
register it with the userspace. But that does not seem to be as trivial
as making it possible to call the now-static i2c_register_adapter()
separately.
BR,
Jani.
>
>>
>> Regards,
>> Bjorn
>>
>> > On Mon, 2021-05-03 at 14:58 -0700, Douglas Anderson wrote:
>> > > It can be helpful to fully register the AUX channel as an i2c bus even
>> > > before the bridge is created. Let's optionally allow bridges to do
>> > > that.
>> > >
>> > > Specifically the case we're running into:
>> > > - The panel driver wants to get its DDC bus at probe time.
>> > > - The ti-sn65dsi86 MIPI-to-eDP bridge code, which provides the DDC
>> > > bus, wants to get the panel at probe time.
>> > >
>> > > The next patches ("drm/bridge: ti-sn65dsi86: Promote the AUX channel
>> > > to its own sub-dev") solves the chicken-and-egg problem by breaking
>> > > the ti-sn65dsi86 driver into sub-devices, but in order for it to
>> > > actually work we need the i2c bus to get registered at probe time and
>> > > not in bridge attach time.
>> > >
>> > > Cc: Lyude Paul
>> > > Cc: Thierry Reding
>> > > Signed-off-by: Douglas Anderson
>> > > ---
>> > >
>> > > Changes in v6:
>> > > - ("drm/dp: Allow an early call to register DDC i2c bus") new for v6.
>> > >
>> > > drivers/gpu/drm/drm_dp_helper.c | 67 +++--
>> > > include/drm/drm_dp_helper.h | 2 +
>> > > 2 files changed, 57 insertions(+), 12 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> > > b/drivers/gpu/drm/drm_dp_helper.c
>> > > index cb56d74e9d38..830294f0b341 100644
>> > > --- a/drivers/gpu/drm/drm_dp_helper.c
>> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
>> > > @@ -1757,6 +1757,49 @@ void drm_dp_aux_init(struct drm_dp_aux *aux)
>> > > }
>> > > EXPORT_SYMBOL(drm_dp_aux_init);
>> > >
>> > > +/**
>> > > + * drm_dp_aux_register_ddc() - register the DDC parts of the aux
>> > > channel
>> > > + * @aux: DisplayPort AUX channel
>> > > + *
>> > > + * This can be called after drm_dp_aux_init() to fully register the ddc
>> > > bus
>> > > + * as an i2c adapter with the rest of Linux.
>> > > + *
>> > > + * If you don't explicitly call this function it will be done
>> > > implicitly as
>> > > + * part of drm_dp_aux_register().
>> > > + *
>> > > + * Returns 0 on success or a negative error code on failure.
>> > > + */
>> > > +int drm_dp_aux_register_ddc(struct drm_dp_aux *aux)
>> > > +{
>> > > + WARN_ON_ONCE(!aux->dev);
>> > > +
>> > > + aux->ddc.class = I2C_CLASS_DDC;
>> > > + aux->ddc.owner = THIS_MODULE;
>> > > + aux->ddc.dev.parent = aux->dev;
>> > > +
>> > > + strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux-
>> > > >dev),
>> > > + sizeof(aux->ddc.name));
>> > > +
>> > > + return i2c_add_adapter(>ddc);
>> > > +}
>> > >
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On 06/05/2021 20:13, Matthew Brost wrote: Basic GuC submission support. This is the first bullet point in the upstreaming plan covered in the following RFC [1]. At a very high level the GuC is a piece of firmware which sits between the i915 and the GPU. It offloads some of the scheduling of contexts from the i915 and programs the GPU to submit contexts. The i915 communicates with the GuC and the GuC communicates with the GPU. GuC submission will be disabled by default on all current upstream platforms behind a module parameter - enable_guc. A value of 3 will enable submission and HuC loading via the GuC. GuC submission should work on all gen11+ platforms assuming the GuC firmware is present. Some thoughts mostly relating to future platforms where GuC will be the only option, and to some extent platforms where it will be possible to turn it on for one reason or another. Debuggability - in the context of having an upstream way/tool for capturing and viewing GuC logs usable for attaching to bug reports. Currently i915 logs, can provide traces via tracepoints and trace printk, and GPU error capture state, which provides often sufficient trail of evidence to debug issues. We need to make sure GuC does is not a black box in this respect. By this I mean it does not hide a large portion of the execution flows from upstream observability. This could mean a tool in IGT to access/capture GuC logs and update bug filing instructions. Leading from here is probably the need for the GuC firmware team to cross the internal-upstream boundary and deal with such bug reports on upstream trackers. Upstream GuC is unlikely to work if we don't have such plan and commitment. Also leading from here is the need for GPU error capture to be on par from day one which is I believe still not there in the firmware. Another, although unrelated, missing feature on my wish list is firmware support for wiring up accurate engine busyness stats to i915 PMU. I believe this is also being worked on but I don't know when is the expected delivery. If we are tracking a TODO list of items somewhere I think these ones should be definitely considered. Regards, Tvrtko
[PATCH 4/4] clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after kernel startup
From: Dillon Min
stm32's clk driver register two ltdc gate clk to clk core by
clk_hw_register_gate() and clk_hw_register_composite()
first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use.
second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver
both of them point to the same offset of stm32's RCC register. after
kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]'
is no one to use. but, actually 'stm32f429_aux_clk[]' is in use.
Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
Signed-off-by: Dillon Min
Acked-by: Stephen Boyd
Link:
https://lore.kernel.org/linux-arm-kernel/1590564453-24499-7-git-send-email-dillon.min...@gmail.com/
---
drivers/clk/clk-stm32f4.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 42ca2dd86aea..f4156a8a6041 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -129,7 +129,6 @@ static const struct stm32f4_gate_data stm32f429_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
};
static const struct stm32f4_gate_data stm32f469_gates[] __initconst = {
@@ -211,7 +210,6 @@ static const struct stm32f4_gate_data stm32f469_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
};
static const struct stm32f4_gate_data stm32f746_gates[] __initconst = {
@@ -286,7 +284,6 @@ static const struct stm32f4_gate_data stm32f746_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 23, "sai2", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
};
static const struct stm32f4_gate_data stm32f769_gates[] __initconst = {
@@ -364,7 +361,6 @@ static const struct stm32f4_gate_data stm32f769_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 23, "sai2", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 30, "mdio", "apb2_div" },
};
--
2.7.4
[PATCH 3/4] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate
From: Dillon Min
This is due to misuse ‘PLL_VCO_SAI' and'PLL_SAI' in clk-stm32f4.c
'PLL_SAI' is 2, 'PLL_VCO_SAI' is 7(defined in
include/dt-bindings/clock/stm32fx-clock.h).
'post_div' point to 'post_div_data[]', 'post_div->pll_num'
is PLL_I2S or PLL_SAI.
'clks[PLL_VCO_SAI]' has valid 'struct clk_hw* ' return
from stm32f4_rcc_register_pll() but, at line 1777 of
driver/clk/clk-stm32f4.c, use the 'clks[post_div->pll_num]',
equal to 'clks[PLL_SAI]', this is invalid array member at that time.
Fixes: 517633ef630e ("clk: stm32f4: Add post divisor for I2S & SAI PLLs")
Signed-off-by: Dillon Min
Acked-by: Stephen Boyd
Link:
https://lore.kernel.org/linux-arm-kernel/1590564453-24499-6-git-send-email-dillon.min...@gmail.com/
---
drivers/clk/clk-stm32f4.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 18117ce5ff85..42ca2dd86aea 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -557,13 +557,13 @@ static const struct clk_div_table post_divr_table[] = {
#define MAX_POST_DIV 3
static const struct stm32f4_pll_post_div_data post_div_data[MAX_POST_DIV] = {
- { CLK_I2SQ_PDIV, PLL_I2S, "plli2s-q-div", "plli2s-q",
+ { CLK_I2SQ_PDIV, PLL_VCO_I2S, "plli2s-q-div", "plli2s-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 0, 5, 0, NULL},
- { CLK_SAIQ_PDIV, PLL_SAI, "pllsai-q-div", "pllsai-q",
+ { CLK_SAIQ_PDIV, PLL_VCO_SAI, "pllsai-q-div", "pllsai-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 8, 5, 0, NULL },
- { NO_IDX, PLL_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
+ { NO_IDX, PLL_VCO_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
STM32F4_RCC_DCKCFGR, 16, 2, 0, post_divr_table },
};
--
2.7.4
[PATCH 2/4] i2c: stm32f4: Fix stmpe811 get xyz data timeout issue
From: Dillon Min
As stm32f429's internal flash is 2Mbytes and compiled kernel
image bigger than 2Mbytes, so we have to load kernel image
to sdram on stm32f429-disco board which has 8Mbytes sdram space.
based on above context, as you knows kernel running on external
sdram is more slower than internal flash. besides, we need read 4
bytes to get touch screen xyz(x, y, pressure) coordinate data in
stmpe811 interrupt.
so, in stm32f4_i2c_handle_rx_done, as i2c read slower than running
in xip mode, have to adjust 'STOP/START bit set position' from last
two bytes to last one bytes. else, will get i2c timeout in reading
touch screen coordinate.
to not bring in side effect, introduce IIC_LAST_BYTE_POS to support xip
kernel or zImage.
Fixes: 62817fc8d282 ("i2c: stm32f4: add driver")
Link:
https://lore.kernel.org/lkml/1591709203-12106-5-git-send-email-dillon.min...@gmail.com/
Signed-off-by: Dillon Min
---
drivers/i2c/busses/i2c-stm32f4.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
index 4933fc8ce3fd..2e41231b9037 100644
--- a/drivers/i2c/busses/i2c-stm32f4.c
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -93,6 +93,12 @@
#define STM32F4_I2C_MAX_FREQ 46U
#define HZ_TO_MHZ 100
+#if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
+#define IIC_LAST_BYTE_POS 1
+#else
+#define IIC_LAST_BYTE_POS 2
+#endif
+
/**
* struct stm32f4_i2c_msg - client specific data
* @addr: 8-bit slave addr, including r/w bit
@@ -439,7 +445,7 @@ static void stm32f4_i2c_handle_rx_done(struct
stm32f4_i2c_dev *i2c_dev)
int i;
switch (msg->count) {
- case 2:
+ case IIC_LAST_BYTE_POS:
/*
* In order to correctly send the Stop or Repeated Start
* condition on the I2C bus, the STOP/START bit has to be set
@@ -454,7 +460,7 @@ static void stm32f4_i2c_handle_rx_done(struct
stm32f4_i2c_dev *i2c_dev)
else
stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
- for (i = 2; i > 0; i--)
+ for (i = IIC_LAST_BYTE_POS; i > 0; i--)
stm32f4_i2c_read_msg(i2c_dev);
reg = i2c_dev->base + STM32F4_I2C_CR2;
@@ -463,7 +469,7 @@ static void stm32f4_i2c_handle_rx_done(struct
stm32f4_i2c_dev *i2c_dev)
complete(_dev->complete);
break;
- case 3:
+ case (IIC_LAST_BYTE_POS+1):
/*
* In order to correctly generate the NACK pulse after the last
* received data byte, we have to enable NACK before reading N-2
--
2.7.4
[PATCH 1/4] drm/panel: Add ilitek ili9341 panel driver
From: Dillon Min This driver combine tiny/ili9341.c mipi_dbi_interface driver with mipi_dpi_interface driver, can support ili9341 with serial mode or parallel rgb interface mode by register configuration. Reviewed-by: Linus Walleij Link: https://lore.kernel.org/lkml/1590378348-8115-7-git-send-email-dillon.min...@gmail.com/ Signed-off-by: Dillon Min --- drivers/gpu/drm/panel/Kconfig| 12 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1285 ++ 3 files changed, 1298 insertions(+) create mode 100755 drivers/gpu/drm/panel/panel-ilitek-ili9341.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 4894913936e9..e4babba17864 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -123,6 +123,18 @@ config DRM_PANEL_ILITEK_IL9322 Say Y here if you want to enable support for Ilitek IL9322 QVGA (320x240) RGB, YUV and ITU-T BT.656 panels. +config DRM_PANEL_ILITEK_ILI9341 + tristate "Ilitek ILI9341 240x320 QVGA panels" + depends on OF && SPI + depends on DRM_KMS_HELPER + depends on DRM_KMS_CMA_HELPER + depends on BACKLIGHT_CLASS_DEVICE + select DRM_MIPI_DBI + help + Say Y here if you want to enable support for Ilitek IL9341 + QVGA (240x320) RGB panels. support serial & parallel rgb + interface. + config DRM_PANEL_ILITEK_ILI9881C tristate "Ilitek ILI9881C-based panels" depends on OF diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index cae4d976c069..0ecde184665d 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o +obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c new file mode 100644 index ..f84983cbb250 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c @@ -0,0 +1,1285 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Ilitek ILI9341 TFT LCD drm_panel driver. + * + * This panel can be configured to support: + * - 16-bit parallel RGB interface + * - 18-bit parallel RGB interface + * - 4-line serial spi interface + * + * Copyright (C) 2020 Dillon Min + * Derived from drivers/drm/gpu/panel/panel-ilitek-ili9322.c + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define ILI9341_RGB_INTERFACE 0xb0 /* RGB Interface Signal Control */ +#define ILI9341_FRC0xb1 /* Frame Rate Control register */ +#define ILI9341_DFC0xb6 /* Display Function Control register */ +#define ILI9341_POWER1 0xc0 /* Power Control 1 register */ +#define ILI9341_POWER2 0xc1 /* Power Control 2 register */ +#define ILI9341_VCOM1 0xc5 /* VCOM Control 1 register */ +#define ILI9341_VCOM2 0xc7 /* VCOM Control 2 register */ +#define ILI9341_POWERA 0xcb /* Power control A register */ +#define ILI9341_POWERB 0xcf /* Power control B register */ +#define ILI9341_PGAMMA 0xe0 /* Positive Gamma Correction register */ +#define ILI9341_NGAMMA 0xe1 /* Negative Gamma Correction register */ +#define ILI9341_DTCA 0xe8 /* Driver timing control A */ +#define ILI9341_DTCB 0xea /* Driver timing control B */ +#define ILI9341_POWER_SEQ 0xed /* Power on sequence register */ +#define ILI9341_3GAMMA_EN 0xf2 /* 3 Gamma enable register */ +#define ILI9341_INTERFACE 0xf6 /* Interface control register */ +#define ILI9341_PRC0xf7 /* Pump ratio control register */ +#define ILI9341_ETMOD 0xb7 /* Entry mode set */ + +#define ILI9341_MADCTL_BGR BIT(3) +#define ILI9341_MADCTL_MV BIT(5) +#define ILI9341_MADCTL_MX BIT(6) +#define ILI9341_MADCTL_MY BIT(7) + + +#define ILI9341_POWER_B_LEN3 +#define ILI9341_POWER_SEQ_LEN 4 +#define ILI9341_DTCA_LEN 3 +#define ILI9341_DTCB_LEN 2 +#define ILI9341_POWER_A_LEN5 +#define ILI9341_DFC_1_LEN 2 +#define ILI9341_FRC_LEN2 +#define ILI9341_VCOM_1_LEN 2 +#define ILI9341_DFC_2_LEN 4 +#define ILI9341_COLUMN_ADDR_LEN4 +#define ILI9341_PAGE_ADDR_LEN 4 +#define
[PATCH 0/4] Fix the i2c/clk bug of stm32 mcu platform
From: Dillon Min
This seriese fix three i2c/clk bug for stm32 f4/f7
- kernel runing in sdram, i2c driver get data timeout
- ltdc clk turn off after kernel console active
- kernel hang in set ltdc clock rate
clk bug found on stm32f429/f469-disco board
Hi Patrice:
below is the guide to verify the patch:
setup test env with following files(link at below 'files link'):
[1] u-boot-dtb.bin
[2] rootfs zip file (used in kernel initramfs)
[3] u-boot's mkimage to create itb file
[4] kernel config file
[5] my itb with-or-without i2c patch
This patch based on kernel commit:
88b06399c9c766c283e070b022b5ceafa4f63f19
Note:
panel-ilitek-ili9341.c is the driver which was submitted last year, but not
get accepted. it's used to setup touch screen calibration, then test i2c.
create itb file(please correct path of 'data'):
./mkimage -f stm32.its stm32.itb
HW setup:
console:
PA9, PA10
usart0
serial@40011000
115200 8n1
-- flash u-boot.bin to stm32f429-disco on PC
$ sudo openocd -f board/stm32f429discovery.cfg -c \
'{PATH-TO-YOUR-UBOOT}/u-boot-dtb.bin 0x0800 exit reset'
-- setup kernel load bootargs at u-boot
U-Boot > setenv bootargs 'console=tty0 console=ttySTM0,115200
root=/dev/ram rdinit=/linuxrc loglevel=8 fbcon=rotate:2'
U-Boot > loady;bootm
(download stm32.dtb or your kernel with itb format, or download zImage, dtb)
-- setup ts_calibrate running env on stm32f429-disco
/ # export TSLIB_CONFFILE=/etc/ts.conf
/ # export TSLIB_TSDEVICE=/dev/input/event0
/ # export TSLIB_CONSOLEDEVICE=none
/ # export TSLIB_FBDEVICE=/dev/fb0
-- clear screen
/ # ./fb
-- run ts_calibrate
/ # ts_calibrate
(you can calibrate touchscreen now, and get below errors)
[ 113.942087] stmpe-i2c0-0041: failed to read regs 0x52: -110
[ 114.063598] stmpe-i2c 0-0041: failed to read reg 0x4b: -16
[ 114.185629] stmpe-i2c 0-0041: failed to read reg 0x40: -16
[ 114.307257] stmpe-i2c 0-0041: failed to write reg 0xb: -16
...
with i2c patch applied, you will find below logs:
RAW-> 3164 908 183 118.110884
TS_READ_RAW> x = 3164, y =908, pressure = 183
RAW-> 3166 922 126 118.138946
TS_READ_RAW> x = 3166, y = 922, pressure = 126
files link:
https://drive.google.com/drive/folders/1qNbjChcB6UGtKzne2F5x9_WG_sZFyo3o?usp=sharing
Dillon Min (4):
drm/panel: Add ilitek ili9341 panel driver
i2c: stm32f4: Fix stmpe811 get xyz data timeout issue
clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate
clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after
kernel startup
drivers/clk/clk-stm32f4.c| 10 +-
drivers/gpu/drm/panel/Kconfig| 12 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1285 ++
drivers/i2c/busses/i2c-stm32f4.c | 12 +-
5 files changed, 1310 insertions(+), 10 deletions(-)
create mode 100755 drivers/gpu/drm/panel/panel-ilitek-ili9341.c
--
2.7.4
