Re: [PATCH v3 1/7] media: Add 2-10-10-10 RGB formats
On 08/02/2023 03:53, Akira Yokosawa wrote:
[+CC: Maruo and Hans, who are listed in the SOB area of offending commit]
Hi Tomi,
I'm observing build failure of "make pdfdocs" against linux-next due to
this change whose commitid is 8d0e3fc61abd.
Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
Signed-off-by: Tomi Valkeinen
---
.../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 3 +
include/uapi/linux/videodev2.h| 3 +
3 files changed, 200 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
index 30f51cd33f99..d330aeb4d3eb 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
@@ -763,6 +763,200 @@ nomenclature that instead use the order of components as
seen in a 24- or
\normalsize
+10 Bits Per Component
+=
+
+These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
+bytes. They are named based on the order of the RGB components as seen in a
+32-bit word, which is then stored in memory in little endian byte order
+(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
+number of bits for each component.
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. tabularcolumns::
|p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+
+.. flat-table:: RGB Formats 10 Bits Per Color Component
+:header-rows: 2
+:stub-columns: 0
+
+* - Identifier
+ - Code
+ - :cspan:`7` Byte 0 in memory
+ - :cspan:`7` Byte 1
+ - :cspan:`7` Byte 2
+ - :cspan:`7` Byte 3
+* -
+ -
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+* .. _V4L2-PIX-FMT-RGBX1010102:
+
+ - ``V4L2_PIX_FMT_RGBX1010102``
+ - 'RX30'
+
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - x
+ - x
+
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ -
This extra "-"
+* .. _V4L2-PIX-FMT-RGBA1010102:
+
+ - ``V4L2_PIX_FMT_RGBA1010102``
+ - 'RA30'
+
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - a\ :sub:`1`
+ - a\ :sub:`0`
+
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ -
, this one
+* .. _V4L2-PIX-FMT-ARGB2101010:
+
+ - ``V4L2_PIX_FMT_ARGB2101010``
+ - 'AR30'
+
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+
+ - a\ :sub:`1`
+ - a\ :sub:`0`
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ -
, and this one causes the Sphinx LaTeX builder emits userspace-api.tex
which causes latexmk error saying:
---
Latexmk: Getting log file 'userspace-api.log'
Latexmk: Examining
[PATCH] gpu: ipu-v3: prg: use devm_platform_get_and_ioremap_resource()
From: Ye Xingchen
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Ye Xingchen
---
drivers/gpu/ipu-v3/ipu-prg.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 196797c1b4b3..3e888c5f62d3 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -358,7 +358,6 @@ EXPORT_SYMBOL_GPL(ipu_prg_channel_configure_pending);
static int ipu_prg_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct resource *res;
struct ipu_prg *prg;
u32 val;
int i, ret;
@@ -367,8 +366,7 @@ static int ipu_prg_probe(struct platform_device *pdev)
if (!prg)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- prg->regs = devm_ioremap_resource(>dev, res);
+ prg->regs = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
if (IS_ERR(prg->regs))
return PTR_ERR(prg->regs);
--
2.25.1
[PATCH] gpu: ipu-v3: pre: use devm_platform_get_and_ioremap_resource()
From: Ye Xingchen
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Ye Xingchen
---
drivers/gpu/ipu-v3/ipu-pre.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index ad82c9e0252f..04229c7852a5 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -271,15 +271,13 @@ u32 ipu_pre_get_baddr(struct ipu_pre *pre)
static int ipu_pre_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct resource *res;
struct ipu_pre *pre;
pre = devm_kzalloc(dev, sizeof(*pre), GFP_KERNEL);
if (!pre)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pre->regs = devm_ioremap_resource(>dev, res);
+ pre->regs = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
if (IS_ERR(pre->regs))
return PTR_ERR(pre->regs);
--
2.25.1
[PATCH] gpu: host1x: mipi: use devm_platform_get_and_ioremap_resource()
From: Ye Xingchen
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Ye Xingchen
---
drivers/gpu/host1x/mipi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
index 2efe12dde8bc..4dcec535ec21 100644
--- a/drivers/gpu/host1x/mipi.c
+++ b/drivers/gpu/host1x/mipi.c
@@ -501,7 +501,6 @@ static int tegra_mipi_probe(struct platform_device *pdev)
{
const struct of_device_id *match;
struct tegra_mipi *mipi;
- struct resource *res;
int err;
match = of_match_node(tegra_mipi_of_match, pdev->dev.of_node);
@@ -515,8 +514,7 @@ static int tegra_mipi_probe(struct platform_device *pdev)
mipi->soc = match->data;
mipi->dev = >dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mipi->regs = devm_ioremap_resource(>dev, res);
+ mipi->regs = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
if (IS_ERR(mipi->regs))
return PTR_ERR(mipi->regs);
--
2.25.1
Re: [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Tue, Feb 07, 2023 at 07:21:48PM -0500, Lyude Paul wrote: > On Tue, 2023-02-07 at 14:11 +0200, Imre Deak wrote: > > On Mon, Feb 06, 2023 at 07:42:32PM -0500, Lyude Paul wrote: > > > On Wed, 2023-02-01 at 17:04 +0200, Imre Deak wrote: > > > > > > > > Yes, this patch should have no functional change, so please check what > > > > would apply to other drivers as well. > > > > > > > > Could you also check Ville's comment about storing start_slot elsewhere > > > > than the atomic state (leaving only time_slots there). I wonder if that > > > > would work, at least it would simplify things I think. > > > > > > Ideally it'd be nice if we could have all this info in the atomic commit, > > > but > > > yeah - you're not the first person to find this a bit confusing. FWIW > > > though, > > > the way we store start_slot right now is intended to follow the same kind > > > of > > > behavior we have with atomic CRTC commit dependencies, I think I also > > > made it > > > that way so all of the state would be in a single place but there's no > > > hard > > > requirement for it. > > > > As I understood the atomic state should be precomputed during atomic > > check and not changed later during the commit phase. In case of > > start_slot this would mean knowing in advance the actual (driver > > specific) disabling / enabling sequence of the payloads, not sure how > > feasible it is to figure that out. start_slot also changes dynamically > > It isn't feasible afaict, which was the main motivation for having the strange > update procedure - this is pretty much something that needs to be determined > at commit time. > > > as each payload is disabled, so these intermediate versions of the field > > would need to be tracked somehow separately from the final (precomputed) > > versions. > > FWIW, the current way this works is that we call > drm_dp_mst_atomic_wait_for_dependencies() in order to ensure that no one's > currently writing to the start_slot field (remember, at this point we may not > have atomic locks held anymore). Then at that point, start_slot in the new > atomic state should hold the current in-hw start_slot value. start_slot isn't > actually set to the new starting slot until drm_dp_add_payload_part1(). That > of course as you pointed out, doesn't help us unless we read all of the > start_slot values before we start changing payloads - since disabling payloads > inevitably changes the start slot of payloads that come afterwards. > > I'll admit I'm a bit surprised this logic was wrong - if I recall the whole > reason I assumed this was OK when writing this code was that since we're > updating one payload at a time, ACT, repeat, that the start slots of each > payload in hardware _would_ actually change in the same way we modify them in > helpers. e.g., my expectation was if we had a bunch of payloads like this: > > Payload #1: 15 slots, start_slot=0 > Payload #2: 15 slots, start_slot=15 > Payload #3: 15 slots, start_slot=30 > > And then disabled say, payload #1, that immediately after we get the ACT that > the payload table in hardware would look like this: > > Payload #2: 15 slots, start_slot=0 > Payload #3: 15 slots, start_slot=15 The above is the actual and expected HW state state yes. > But it sounds like it actually would look like this in the real world? > > Payload #2: 15 slots, start_slot=15 > Payload #3: 15 slots, start_slot=30 No, the problem currently is not that start_slot of the subsequent payloads are not shifted towards the beginning. Rather the atomic state doesn't get updated properly, becoming out of sync with the HW. For instance in a commit resizing payload #1, in the commit phase (intel_atomic_commit_tail()) will begin by removing payload #1. The initial state is old payload state new payload state Payload #1: 15 slots, start_slot=020 slots, start_slot=0 Payload #2: 15 slots, start_slot=15 15 slots, start_slot=15 Payload #3: 15 slots, start_slot=30 15 slots, start_slot=30 mgr->next_start_slot = 45 intel_mst_disable_dp() will pass the old MST and payload state to drm_dp_remove_payload(): The MST state was added during atomic check, since payload #1 changed, then intel_atomic_commit() -> drm_atomic_helper_swap_state() sets the MST current state (returned by drm_atomic_get_mst_topology_state()) to point to the old state. So at the point drm_dp_remove_payload() returns we have: old payload state new payload state Payload #1: 15 slots, start_slot=-1 20 slots, start_slot=0 Payload #2: 15 slots, start_slot=015 slots, start_slot=15 Payload #3: 15 slots, start_slot=15 15 slots, start_slot=30 mgr->next_start_slot = 30 then after re-enabling payload #1, after drm_dp_add_payload_part1() returns (passing to it the new MST and payload state) we have: old payload state new payload state Payload #1: 15 slots, start_slot=-1 20 slots, start_slot=30 Payload #2: 15 slots, start_slot=015 slots, start_slot=15
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
Hi Ville,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Ville-Syrjala/drm-Introduce-plane-SIZE_HINTS-property/20230208-121141
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230208040911.12590-2-ville.syrjala%40linux.intel.com
patch subject: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
config: x86_64-rhel-8.3-kselftests
(https://download.01.org/0day-ci/archive/20230208/202302081454.aonxo1kr-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/419642b423bdc6e337b5daabecb51173dd206cb5
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ville-Syrjala/drm-Introduce-plane-SIZE_HINTS-property/20230208-121141
git checkout 419642b423bdc6e337b5daabecb51173dd206cb5
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_plane.c:1601: warning: expecting prototype for
>> drm_plane_add_size_hint_property(). Prototype was for
>> drm_plane_add_size_hints_property() instead
vim +1601 drivers/gpu/drm/drm_plane.c
1585
1586 /**
1587 * drm_plane_add_size_hint_property - create a size hint property
1588 *
1589 * @plane: drm plane
1590 * @hints: size hints
1591 * @num_hints: number of size hints
1592 *
1593 * Create a size hints property for the plane.
1594 *
1595 * RETURNS:
1596 * Zero for success or -errno
1597 */
1598 int drm_plane_add_size_hints_property(struct drm_plane *plane,
1599const struct drm_plane_size_hint
*hints,
1600int num_hints)
> 1601 {
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
Hi Ville,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Ville-Syrjala/drm-Introduce-plane-SIZE_HINTS-property/20230208-121141
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230208040911.12590-2-ville.syrjala%40linux.intel.com
patch subject: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
config: m68k-allyesconfig
(https://download.01.org/0day-ci/archive/20230208/202302081339.rlz6hx1b-...@intel.com/config)
compiler: m68k-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/419642b423bdc6e337b5daabecb51173dd206cb5
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ville-Syrjala/drm-Introduce-plane-SIZE_HINTS-property/20230208-121141
git checkout 419642b423bdc6e337b5daabecb51173dd206cb5
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=m68k olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=m68k SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_plane.c:1601: warning: expecting prototype for
>> drm_plane_add_size_hint_property(). Prototype was for
>> drm_plane_add_size_hints_property() instead
vim +1601 drivers/gpu/drm/drm_plane.c
1585
1586 /**
1587 * drm_plane_add_size_hint_property - create a size hint property
1588 *
1589 * @plane: drm plane
1590 * @hints: size hints
1591 * @num_hints: number of size hints
1592 *
1593 * Create a size hints property for the plane.
1594 *
1595 * RETURNS:
1596 * Zero for success or -errno
1597 */
1598 int drm_plane_add_size_hints_property(struct drm_plane *plane,
1599const struct drm_plane_size_hint
*hints,
1600int num_hints)
> 1601 {
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[PATCH 2/2] drm/i915: Add SIZE_HINTS property for cursors
From: Ville Syrjälä
Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.
We can't really enumerate all supported cursor sizes on
the platforms where the cursor height can vary freely, so
for simplicity we'll just expose all square+POT sizes between
each platform's min and max cursor limits.
Depending on the platform this will give us one
of three results:
- 64x64,128x128,256x256,512x512
- 64x64,128x128,256x256
- 64x64
Cc: Simon Ser
Cc: Jonas Ådahl
Cc: Daniel Stone
Cc: Pekka Paalanen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 24 +
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index c3173c0c2068..cb6cf3009727 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -757,6 +757,28 @@ static const struct drm_plane_funcs
intel_cursor_plane_funcs = {
.format_mod_supported = intel_cursor_format_mod_supported,
};
+static void intel_cursor_add_size_hints_property(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+ const struct drm_mode_config *config = >drm.mode_config;
+ struct drm_plane_size_hint hints[4];
+ int size, max_size, num_hints = 0;
+
+ max_size = min(config->cursor_width, config->cursor_height);
+
+ /* for simplicity only enumerate the supported square+POT sizes */
+ for (size = 64; size <= max_size; size *= 2) {
+ if (drm_WARN_ON(>drm, num_hints >= ARRAY_SIZE(hints)))
+ break;
+
+ hints[num_hints].width = size;
+ hints[num_hints].height = size;
+ num_hints++;
+ }
+
+ drm_plane_add_size_hints_property(>base, hints, num_hints);
+}
+
struct intel_plane *
intel_cursor_plane_create(struct drm_i915_private *dev_priv,
enum pipe pipe)
@@ -815,6 +837,8 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_180);
+ intel_cursor_add_size_hints_property(cursor);
+
zpos = RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1;
drm_plane_create_zpos_immutable_property(>base, zpos);
--
2.39.1
[PATCH 1/2] drm: Introduce plane SIZE_HINTS property
From: Ville Syrjälä
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.
Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
stragey is desirable.
Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.
A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.
Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.
Cc: Simon Ser
Cc: Jonas Ådahl
Cc: Daniel Stone
Cc: Pekka Paalanen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_mode_config.c | 7 +++
drivers/gpu/drm/drm_plane.c | 33 +++
include/drm/drm_mode_config.h | 5 +
include/drm/drm_plane.h | 4
include/uapi/drm/drm_mode.h | 5 +
5 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 87eb591fe9b5..21860f94a18c 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+ "SIZE_HINTS", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.size_hints_property = prop;
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 24e7998d1731..d0a277f4be1f 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1582,3 +1582,36 @@ int drm_plane_create_scaling_filter_property(struct
drm_plane *plane,
return 0;
}
EXPORT_SYMBOL(drm_plane_create_scaling_filter_property);
+
+/**
+ * drm_plane_add_size_hint_property - create a size hint property
+ *
+ * @plane: drm plane
+ * @hints: size hints
+ * @num_hints: number of size hints
+ *
+ * Create a size hints property for the plane.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_plane_add_size_hints_property(struct drm_plane *plane,
+ const struct drm_plane_size_hint *hints,
+ int num_hints)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_mode_config *config = >mode_config;
+ struct drm_property_blob *blob;
+
+ blob = drm_property_create_blob(dev,
+ array_size(sizeof(hints[0]), num_hints),
+ hints);
+ if (IS_ERR(blob))
+ return PTR_ERR(blob);
+
+ drm_object_attach_property(>base, config->size_hints_property,
+ blob->base.id);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_plane_add_size_hints_property);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index e5b053001d22..ed9f6938dca1 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -949,6 +949,11 @@ struct drm_mode_config {
*/
struct drm_property *modifiers_property;
+ /**
+* @size_hints_property: Plane SIZE_HINTS property.
+*/
+ struct drm_property *size_hints_property;
+
/* cursor size */
uint32_t cursor_width, cursor_height;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 51291983ea44..1997d7d64b69 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -32,6 +32,7 @@
#include
struct drm_crtc;
+struct drm_plane_size_hint;
struct drm_printer;
struct drm_modeset_acquire_ctx;
@@ -945,5 +946,8 @@ drm_plane_get_damage_clips(const struct drm_plane_state
*state);
int drm_plane_create_scaling_filter_property(struct drm_plane *plane,
unsigned int supported_filters);
+int drm_plane_add_size_hints_property(struct drm_plane *plane,
+ const struct drm_plane_size_hint *hints,
+ int num_hints);
#endif
diff --git
[PATCH 0/2] drm: Add plane SIZE_HINTS property
From: Ville Syrjälä Proposal for a new plane SIZE_HINTS property to essentially replace the cursor size caps, based on recent discussion in this gitlab bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7687 As for userspace, so far I only did a quick modetest blob decoder (mainly to verify that it looks correct): https://gitlab.freedesktop.org/vsyrjala/libdrm/-/commits/plane_size_hints Didn't yet update my modesetting ddx cursor size patch to use this or anything. Cc: Simon Ser Cc: Jonas Ådahl Cc: Daniel Stone Cc: Pekka Paalanen Ville Syrjälä (2): drm: Introduce plane SIZE_HINTS property drm/i915: Add SIZE_HINTS property for cursors drivers/gpu/drm/drm_mode_config.c | 7 + drivers/gpu/drm/drm_plane.c | 33 + drivers/gpu/drm/i915/display/intel_cursor.c | 24 +++ include/drm/drm_mode_config.h | 5 include/drm/drm_plane.h | 4 +++ include/uapi/drm/drm_mode.h | 5 6 files changed, 78 insertions(+) -- 2.39.1
[PATCH 3/3] arm64: dts: qcom: sc8280xp: Enable GPU related nodes
From: Bjorn Andersson
Add memory reservation for the zap-shader and enable the Adreno SMMU,
GPU clock controller, GMU and the GPU nodes for the SC8280XP CRD and the
Lenovo ThinkPad X13s.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 26 +++
.../qcom/sc8280xp-lenovo-thinkpad-x13s.dts| 26 +++
2 files changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
index 35b63c3962f0..1d1ad43040ac 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
@@ -203,6 +203,11 @@ vreg_wwan: regulator-wwan {
};
reserved-memory {
+ gpu_mem: gpu-mem@8bf0 {
+ reg = <0 0x8bf0 0 0x2000>;
+ no-map;
+ };
+
linux,cma {
compatible = "shared-dma-pool";
size = <0x0 0x800>;
@@ -252,6 +257,10 @@ usb1_sbu_mux: endpoint {
};
};
+_smmu {
+ status = "okay";
+};
+
_rsc {
pmc8280-1-rpmh-regulators {
compatible = "qcom,pm8350-rpmh-regulators";
@@ -369,6 +378,23 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ zap-shader {
+ memory-region = <_mem>;
+ firmware-name = "qcom/sc8280xp/qcdxkmsuc8280.mbn";
+ };
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 4ef15edd6c0f..7967e951a8ee 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -256,6 +256,11 @@ vreg_wwan: regulator-wwan {
};
reserved-memory {
+ gpu_mem: gpu-mem@8bf0 {
+ reg = <0 0x8bf0 0 0x2000>;
+ no-map;
+ };
+
linux,cma {
compatible = "shared-dma-pool";
size = <0x0 0x800>;
@@ -351,6 +356,10 @@ usb1_sbu_mux: endpoint {
};
};
+_smmu {
+ status = "okay";
+};
+
_rsc {
pmc8280-1-rpmh-regulators {
compatible = "qcom,pm8350-rpmh-regulators";
@@ -484,6 +493,23 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ zap-shader {
+ memory-region = <_mem>;
+ firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn";
+ };
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
--
2.39.1
[PATCH 1/3] drm/msm/adreno: Add Adreno A690 support
From: Bjorn Andersson
Introduce support for the Adreno A690, found in Qualcomm SC8280XP.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 120 -
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 34 ++
drivers/gpu/drm/msm/adreno/adreno_device.c | 14 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10 +-
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index aae60cbd9164..81dfcc5073ad 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -588,6 +588,63 @@ const struct adreno_reglist a660_hwcg[] = {
{},
};
+const struct adreno_reglist a690_hwcg[] = {
+ {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220},
+ {REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0080},
+ {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xF3CF},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY4_TP0, 0x0001},
+ {REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RB0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RB0, 0x0100},
+ {REG_A6XX_RBBM_CLOCK_CNTL_CCU0, 0x2220},
+ {REG_A6XX_RBBM_CLOCK_HYST_RB_CCU0, 0x00040F00},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RAC, 0x25222022},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RAC, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_RAC, 0x0011},
+ {REG_A6XX_RBBM_CLOCK_HYST_RAC, 0x00445044},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TSE_RAS_RBBM, 0x0422},
+ {REG_A6XX_RBBM_CLOCK_MODE_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_MODE_GPC, 0x0022},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ_2, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_MODE_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TSE_RAS_RBBM, 0x4000},
+ {REG_A6XX_RBBM_CLOCK_DELAY_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GPC, 0x0200},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_TSE_RAS_RBBM, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_GPC, 0x04104004},
+ {REG_A6XX_RBBM_CLOCK_HYST_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TEX_FCHE, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TEX_FCHE, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_TEX_FCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_UCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_UCHE, 0x0004},
+ {REG_A6XX_RBBM_CLOCK_DELAY_UCHE, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_CNTL, 0x8AA8AA82},
+ {REG_A6XX_RBBM_ISDB_CNT, 0x0182},
+ {REG_A6XX_RBBM_RAC_THRESHOLD_CNT, 0x},
+ {REG_A6XX_RBBM_SP_HYST_CNT, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x0555},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_MODE_CNTL, 0x20200},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_DELAY_CNTL, 0x10111},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_HYST_CNTL, 0x},
+ {}
+};
+
static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -747,6 +804,45 @@ static const u32 a660_protect[] = {
A6XX_PROTECT_NORDWR(0x1f8c0, 0x), /* note: infinite range */
};
+/* These are for a690 */
+static const u32 a690_protect[] = {
+ A6XX_PROTECT_RDONLY(0x0, 0x004ff),
+ A6XX_PROTECT_RDONLY(0x00501, 0x1),
+ A6XX_PROTECT_RDONLY(0x0050b, 0x002f4),
+ A6XX_PROTECT_NORDWR(0x0050e, 0x0),
+ A6XX_PROTECT_NORDWR(0x00510, 0x0),
+ A6XX_PROTECT_NORDWR(0x00534, 0x0),
+ A6XX_PROTECT_NORDWR(0x00800, 0x00082),
+ A6XX_PROTECT_NORDWR(0x008a0, 0x8),
+ A6XX_PROTECT_NORDWR(0x008ab, 0x00024),
+ A6XX_PROTECT_RDONLY(0x008d0, 0x000bc),
+ A6XX_PROTECT_NORDWR(0x00900, 0x0004d),
+ A6XX_PROTECT_NORDWR(0x0098d, 0x00272),
+ A6XX_PROTECT_NORDWR(0x00e00, 0x1),
+ A6XX_PROTECT_NORDWR(0x00e03, 0xc),
+ A6XX_PROTECT_NORDWR(0x03c00, 0x000c3),
+ A6XX_PROTECT_RDONLY(0x03cc4, 0x01fff),
+ A6XX_PROTECT_NORDWR(0x08630, 0x001cf),
+ A6XX_PROTECT_NORDWR(0x08e00, 0x0),
+ A6XX_PROTECT_NORDWR(0x08e08, 0x8),
+ A6XX_PROTECT_NORDWR(0x08e50, 0x0001f),
+ A6XX_PROTECT_NORDWR(0x08e80, 0x0027f),
+
[PATCH 2/3] arm64: dts: qcom: sc8280xp: Add GPU related nodes
From: Bjorn Andersson
Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the
SC8280XP.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 171 +
1 file changed, 171 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index fcd393444f47..94e8d0da9d7b 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -2275,6 +2276,176 @@ tcsr: syscon@1fc {
reg = <0x0 0x01fc 0x0 0x3>;
};
+ gpu: gpu@3d0 {
+ compatible = "qcom,adreno-690.0", "qcom,adreno";
+ reg = <0 0x03d0 0 0x4>,
+ <0 0x03d9e000 0 0x1000>,
+ <0 0x03d61000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem",
+ "cx_dbgc";
+ interrupts = ;
+ iommus = <_smmu 0 0xc00>, <_smmu 1 0xc00>;
+ operating-points-v2 = <_opp_table>;
+ qcom,gmu = <>;
+ interconnects = <_noc MASTER_GFX3D 0 _virt
SLAVE_EBI1 0>;
+ interconnect-names = "gfx-mem";
+ #cooling-cells = <2>;
+
+ status = "disabled";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-27000 {
+ opp-hz = /bits/ 64 <27000>;
+ opp-level =
;
+ opp-peak-kBps = <451000>;
+ };
+
+ opp-41000 {
+ opp-hz = /bits/ 64 <41000>;
+ opp-level = ;
+ opp-peak-kBps = <1555000>;
+ };
+
+ opp-5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-level =
;
+ opp-peak-kBps = <1555000>;
+ };
+
+ opp-54700 {
+ opp-hz = /bits/ 64 <54700>;
+ opp-level =
;
+ opp-peak-kBps = <1555000>;
+ };
+
+ opp-60600 {
+ opp-hz = /bits/ 64 <60600>;
+ opp-level = ;
+ opp-peak-kBps = <2736000>;
+ };
+
+ opp-64000 {
+ opp-hz = /bits/ 64 <64000>;
+ opp-level =
;
+ opp-peak-kBps = <2736000>;
+ };
+
+ opp-69000 {
+ opp-hz = /bits/ 64 <69000>;
+ opp-level =
;
+ opp-peak-kBps = <2736000>;
+ };
+ };
+ };
+
+ gmu: gmu@3d6a000 {
+ compatible="qcom,adreno-gmu-690.0", "qcom,adreno-gmu";
+ reg = <0 0x03d6a000 0 0x34000>,
+ <0 0x03de 0 0x1>,
+ <0 0x0b29 0 0x1>,
+ <0 0x0b49 0 0x1>;
+ reg-names = "gmu", "rscc", "gmu_pdc", "gmu_pdc_seq";
+ interrupts = ,
+;
+ interrupt-names = "hfi", "gmu";
+ clocks = < GPU_CC_CX_GMU_CLK>,
+< GPU_CC_CXO_CLK>,
+< GCC_DDRSS_GPU_AXI_CLK>,
+< GCC_GPU_MEMNOC_GFX_CLK>,
+< GPU_CC_AHB_CLK>,
+< GPU_CC_HUB_CX_INT_CLK>,
+< GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>,
+<_qmp>;
+ clock-names = "gmu",
+ "cxo",
+ "axi",
+ "memnoc",
+ "ahb",
+ "hub",
+
[PATCH 0/3] drm/msm/adreno: GPU support on SC8280XP
This series introduces support for A690 in the DRM/MSM driver and enables it for the two SC8280XP laptops. Bjorn Andersson (3): drm/msm/adreno: Add Adreno A690 support arm64: dts: qcom: sc8280xp: Add GPU related nodes arm64: dts: qcom: sc8280xp: Enable GPU related nodes arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 26 +++ .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts| 26 +++ arch/arm64/boot/dts/qcom/sc8280xp.dtsi| 171 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 120 +++- drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 34 drivers/gpu/drm/msm/adreno/adreno_device.c| 14 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 +- 7 files changed, 396 insertions(+), 5 deletions(-) -- 2.39.1
[PATCH] drm/rockchip: dsi: Remove the unused function dsi_read()
The function dsi_read is defined in the dw-mipi-dsi-rockchip.c file, but
not called elsewhere, so remove this unused function.
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:362:19: warning: unused
function 'dsi_read'.
Reported-by: Abaci Robot
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3984
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 7901c3babc8c..917e79951aac 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -359,11 +359,6 @@ static inline void dsi_write(struct dw_mipi_dsi_rockchip
*dsi, u32 reg, u32 val)
writel(val, dsi->base + reg);
}
-static inline u32 dsi_read(struct dw_mipi_dsi_rockchip *dsi, u32 reg)
-{
- return readl(dsi->base + reg);
-}
-
static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi_rockchip *dsi,
u8 test_code,
u8 test_data)
--
2.20.1.7.g153144c
Re: remove arch/sh
On 2/7/23 01:06, John Paul Adrian Glaubitz wrote: > Hello Christoph! > > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: >> On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: >>> We have had a discussion between multiple people invested in the SuperH >>> port and >>> I have decided to volunteer as a co-maintainer of the port to support Rich >>> Felker >>> when he isn't available. >> >> So, this still isn't reflected in MAINTAINERS in linux-next. When >> do you plan to take over? What platforms will remain supported and >> what can we start dropping due to being unused and unmaintained? > > I'm getting everything ready now with Geert's help and I have a probably dumb > question regarding the MAINTAINERS file change: Shall I just add myself as an > additional maintainer first or shall I also drop Yoshinori Sato? > > Also, is it desirable to add a "T:" entry for the kernel tree? Yes, definitely. thanks. -- ~Randy
Re: [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Tue, 2023-02-07 at 14:11 +0200, Imre Deak wrote: > On Mon, Feb 06, 2023 at 07:42:32PM -0500, Lyude Paul wrote: > > On Wed, 2023-02-01 at 17:04 +0200, Imre Deak wrote: > > > > > > Yes, this patch should have no functional change, so please check what > > > would apply to other drivers as well. > > > > > > Could you also check Ville's comment about storing start_slot elsewhere > > > than the atomic state (leaving only time_slots there). I wonder if that > > > would work, at least it would simplify things I think. > > > > Ideally it'd be nice if we could have all this info in the atomic commit, > > but > > yeah - you're not the first person to find this a bit confusing. FWIW > > though, > > the way we store start_slot right now is intended to follow the same kind of > > behavior we have with atomic CRTC commit dependencies, I think I also made > > it > > that way so all of the state would be in a single place but there's no hard > > requirement for it. > > As I understood the atomic state should be precomputed during atomic > check and not changed later during the commit phase. In case of > start_slot this would mean knowing in advance the actual (driver > specific) disabling / enabling sequence of the payloads, not sure how > feasible it is to figure that out. start_slot also changes dynamically It isn't feasible afaict, which was the main motivation for having the strange update procedure - this is pretty much something that needs to be determined at commit time. > as each payload is disabled, so these intermediate versions of the field > would need to be tracked somehow separately from the final (precomputed) > versions. FWIW, the current way this works is that we call drm_dp_mst_atomic_wait_for_dependencies() in order to ensure that no one's currently writing to the start_slot field (remember, at this point we may not have atomic locks held anymore). Then at that point, start_slot in the new atomic state should hold the current in-hw start_slot value. start_slot isn't actually set to the new starting slot until drm_dp_add_payload_part1(). That of course as you pointed out, doesn't help us unless we read all of the start_slot values before we start changing payloads - since disabling payloads inevitably changes the start slot of payloads that come afterwards. I'll admit I'm a bit surprised this logic was wrong - if I recall the whole reason I assumed this was OK when writing this code was that since we're updating one payload at a time, ACT, repeat, that the start slots of each payload in hardware _would_ actually change in the same way we modify them in helpers. e.g., my expectation was if we had a bunch of payloads like this: Payload #1: 15 slots, start_slot=0 Payload #2: 15 slots, start_slot=15 Payload #3: 15 slots, start_slot=30 And then disabled say, payload #1, that immediately after we get the ACT that the payload table in hardware would look like this: Payload #2: 15 slots, start_slot=0 Payload #3: 15 slots, start_slot=15 But it sounds like it actually would look like this in the real world? Payload #2: 15 slots, start_slot=15 Payload #3: 15 slots, start_slot=30 So I'm curious, is there something I missed here? At what point does the MST hub at the other end decide that it's time to move the start slots back? (keep in mind, the MST specification does explicitly mention that there should never be holes in the payload table - so something has to be shifting the payloads back). > > > So if you guys think it'd be better design-wise to store this something > > else, > > I've got no strong feelings either way > > > > > > > For 0-2: > > > > > > > > Reviewed-by: Lyude Paul > > > > > > Thanks. > > > > > > > > > > > > > > > > > Cc: Lyude Paul > > > > > Cc: Ville Syrjälä > > > > > Cc: Ben Skeggs > > > > > Cc: Karol Herbst > > > > > Cc: Harry Wentland > > > > > Cc: Alex Deucher > > > > > Cc: Wayne Lin > > > > > Cc: sta...@vger.kernel.org # 6.1 > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Reviewed-by: Ville Syrjälä > > > > > Signed-off-by: Imre Deak > > > > > --- > > > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 > > > > > ++- > > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++- > > > > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- > > > > > include/drm/display/drm_dp_mst_helper.h | 3 ++- > > > > > 5 files changed, 21 insertions(+), 16 deletions(-) > > > > > > > > > > diff --git > > > > > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > index a50319fc42b11..180d3893b68da 100644 > > > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > @@ -208,7 +208,7 @@ bool > > > > > dm_helpers_dp_mst_write_payload_allocation_table( > > > > > if (enable)
Re: [PATCH] drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()
Sorry, I accidentally sent this reply offlist! Resending, my apologies... On 07/02/2023 20.29, Thomas Zimmermann wrote: > Hi > > Am 05.02.23 um 13:51 schrieb Asahi Lina: >> Other functions touching shmem->sgt take the pages lock, so do that here > > Really? I was just locking at the Lima driver and it apparently access > sgt without locking in [1]. Not that I disagree with the patch in general. It looks like that lima code is reimplementing a lot of helper functionality. I imagine it was written before the helpers...? I think most of that function could be replaced with a call to drm_gem_shmem_get_pages_sgt(). I don't know exactly how the lima driver works, but if there is a possibility of multiple calls to lima_heap_alloc() on the same BO without a higher-level mutex protecting it, I would say that code is racy. For the Rust abstraction (and really for a well-designed API in general) you want a coherent story on locking, so I think it makes sense to take the pages lock to manipulate the sgt, since drm_gem_shmem_get_pages_sgt() was already taking the pages lock for inner things anyway. Otherwise it's impossible to make safe without adding another discrete layer of locking around everything (I can't just take the pages lock in the wrapper since drm_gem_shmem_get_pages_sgt() would try to recursively lock it). > Best regards > Thomas > > [1] > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/lima/lima_gem.c#L21 ~~ Lina
[PATCH] drm/amd/display: fix glitches on hw rotation without pipe split
Fix glitches when moving cursor close to the edge on a rotated screen for drivers with one pipe (without pipe split) by halving dst_x_offset. Reported-by: Xaver Hugl Signed-off-by: Melissa Wen --- Hi, I'm not sure if having dst_x_offset (or only for the one pipe case) is the right solution, but it solves the issue on different devices when the pipe split policy is AVOID. Context: Some artifacts appear on HW rotated screen when moving the cursor close to the edge, as reported in: https://gitlab.freedesktop.org/drm/amd/-/issues/2247 This issue was initially reported on DCN 3.0.1 and it's not present in DCN 2.1 by default, for example. These two drivers follow different pipe_split_policy, where there is no pipe split on DCN 3.0.1 (AVOID), but we see pipe splitting on DCN 2.1 (MPC_SPLIT_AVOID_MULT_DISP). Splitting (or not) the pipe changes the way DC calculates cursor movements and its position, as we can see in dcn10_set_cursor_position(). In addition, it's possible to reproduce the same issue found on DCN 3.0.1 by setting DCN 2.1 to avoid pipe splitting plus rotating the screen to any angle different from zero. However, from my experiments, setting DCN 3.0.1 to a different pipe split policy makes the system unstable and causes GPU reset (even though DYNAMIC seems to be the default policy for DC). I see that plugging/unplugging the charger changed the intensity of these artifacts and also see some temporary changes with different power performance settings. Keeping that in mind, I verified calculations and register updates related to cursor movements (dcn10_set_cursor_position(), hubp2_cursor_set_position()), and we can see that some clk values participates in the final result of dst_x_offset. After halving dst_x_offset, the artifacts no longer appear and it solves the problem when pipe splitting is not allowed. This change doesn't affect the correct behavior with more than one pipe, but may affect the optimal setup of bandwidth and clocks. Perhaps, the current values doesn't deliver the right performance when the pipe is not split and halving dst_x_offset is exactly the right step for only one pipe, but not for pipe split. Finally, if this is not the right solution, I appreciate any feedback to address this problem correctly. Thanks, Melissa drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c index 4566bc7abf17..1ff85d81237e 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c @@ -1018,7 +1018,7 @@ void hubp2_cursor_set_position( src_y_offset = y_pos - (cursor_height - y_hotspot); } - dst_x_offset = (src_x_offset >= 0) ? src_x_offset : 0; + dst_x_offset = (src_x_offset >= 0) ? src_x_offset / 2 : 0; dst_x_offset *= param->ref_clk_khz; dst_x_offset /= param->pixel_clk_khz; -- 2.39.0
Re: [Intel-gfx] [PATCH 4/4] drm/i915/selftest: Use forcewake to sanity check engine wa lists
On Wed, Feb 01, 2023 at 02:28:31PM -0800, Matt Roper wrote:
> Although register information in the bspec includes a field that is
> supposed to reflect a register's reset characteristics (i.e., whether a
> register maintains its value through engine resets), it's been
> discovered that this information is incorrect for some register ranges
> (i.e., registers that are not affected by engine resets are tagged in a
> way that indicates they would be).
>
> We can sanity check workaround registers placed on the RCS/CCS engine
> workaround lists (including those placed there via the
> general_render_compute_wa_init() function) by comparing against the
> forcewake table. As far as we know, there's never a case where a
> register that lives outside the RENDER powerwell will be reset by an
> RCS/CCS engine reset.
>
> Signed-off-by: Matt Roper
> ---
> .../gpu/drm/i915/gt/selftest_workarounds.c| 52 +++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> index 14a8b25b6204..1bc8febc5c1d 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> @@ -1362,12 +1362,64 @@ live_engine_reset_workarounds(void *arg)
> return ret;
> }
>
> +/*
> + * The bspec's documentation for register reset behavior can be unreliable
> for
> + * some MMIO ranges. But in general we do not expect registers outside the
> + * RENDER forcewake domain to be reset by RCS/CCS engine resets. If we find
> + * workaround registers on an RCS or CCS engine's list, it likely indicates
I think "workaround registers" is too general and makes the sentence a bit
confusing. I believe you mean those registers mentioned in the previous
sentence, right? Maybe s/workaround registers/said registers/?
> + * the register is misdocumented in the bspec and the workaround
> implementation
> + * should be moved to the GT workaround list instead.
> + */
> +static int
> +live_check_engine_workarounds_fw(void *arg)
> +{
> + struct intel_gt *gt = arg;
> + struct intel_engine_cs *engine;
> + struct wa_lists *lists;
> + enum intel_engine_id id;
> + int ret = 0;
> +
> + lists = kzalloc(sizeof(*lists), GFP_KERNEL);
> + if (!lists)
> + return -ENOMEM;
> +
> + reference_lists_init(gt, lists);
> +
> + for_each_engine(engine, gt, id) {
> + struct i915_wa_list *wal = >engine[id].wa_list;
> + struct i915_wa *wa;
> + int i;
> +
> + if (engine->class != RENDER_CLASS &&
> + engine->class != COMPUTE_CLASS)
> + continue;
> +
> + for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
> + enum forcewake_domains fw;
> +
> + fw = intel_uncore_forcewake_for_reg(gt->uncore, wa->reg,
> + FW_REG_READ |
> FW_REG_WRITE);
> + if ((fw & FORCEWAKE_RENDER) == 0) {
> + pr_err("%s: Register %#x not in RENDER
> forcewake domain!\n",
> +engine->name,
> i915_mmio_reg_offset(wa->reg));
I think it is safer to use the correct member (wa->reg vs wa->mcr_reg) according
to the value of wa->is_mcr. Coincidently the reg member for both types have the
same offset in the struct, but I do not think we should rely on that.
One issue is that, unlike i915_mmio_reg_offset(),
intel_uncore_forcewake_for_reg() is not implemented with generics and expects
i915_reg_t. A workaround here would be "converting" the wa->mcr_reg (when
wa->is_mcr holds) an i915_reg_t by copying the correct fields. While this is
trivial since both types have only one field, I think the proper way
(future-proof) of doing that is by having a dedicated function/macro to do the
transformation.
Thinking about an alternative approach, do you think we could say that
i915_mcr_reg_t will always have the same fields as i915_reg_t? In that case, we
could tweak the type definition (or at least formalize via code documentation)
to reflect that and then it would be okay to always use wa->reg here, as
i915_mcr_reg_t would be thought as a subclass of i915_reg_t.
> + ret = -EINVAL;
> + }
> + }
> + }
> +
> + reference_lists_fini(gt, lists);
> + kfree(lists);
> +
> + return ret;
> +}
> +
> int intel_workarounds_live_selftests(struct drm_i915_private *i915)
> {
> static const struct i915_subtest tests[] = {
> SUBTEST(live_dirty_whitelist),
> SUBTEST(live_reset_whitelist),
> SUBTEST(live_isolated_whitelist),
> + SUBTEST(live_check_engine_workarounds_fw),
> SUBTEST(live_gpu_reset_workarounds),
> SUBTEST(live_engine_reset_workarounds),
> };
> --
> 2.39.1
>
Re: [PATCH v2 0/6] More drm_dbg to guc_dbg changes
On 07.02.2023 06:07, john.c.harri...@intel.com wrote: > From: John Harrison > > Update more print messages to the new scheme. > > v2: Also change all errors to %pe rather than %d (MichalW). > Few other tweaks. > > Signed-off-by: John Harrison LGTM, series is Reviewed-by: Michal Wajdeczko > > > John Harrison (6): > drm/i915/guc: More debug print updates - UC firmware > drm/i915/guc: More debug print updates - GSC firmware > drm/i915/guc: More debug print updates - GuC reg capture > drm/i915/guc: More debug print updates - GuC selftests > drm/i915/guc: More debug print updates - GuC SLPC > drm/i915/guc: More debug print updates - GuC logging > > drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 + > drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 9 +- > drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +- > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 3 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 + > drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 61 - > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 42 +++ > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +- > drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 42 --- > .../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++-- > .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 11 +- > 13 files changed, 174 insertions(+), 205 deletions(-) >
Re: [PATCH v11 3/9] drm/display: Add Type-C switch helpers
Hi Pin-yen,
[...]
> +static int drm_dp_register_mode_switch(struct device *dev,
> +struct fwnode_handle *fwnode,
> +struct drm_dp_typec_switch_desc
> *switch_desc,
> +void *data, typec_mux_set_fn_t mux_set)
> +{
> + struct drm_dp_typec_port_data *port_data;
> + struct typec_mux_desc mux_desc = {};
> + char name[32];
> + u32 port_num;
> + int ret;
> +
> + ret = fwnode_property_read_u32(fwnode, "reg", _num);
> + if (ret) {
> + dev_err(dev, "Failed to read reg property: %d\n", ret);
> + return ret;
> + }
> +
> + port_data = _desc->typec_ports[port_num];
> + port_data->data = data;
> + port_data->port_num = port_num;
> + port_data->fwnode = fwnode;
> + mux_desc.fwnode = fwnode;
> + mux_desc.drvdata = port_data;
> + snprintf(name, sizeof(name), "%pfwP-%u", fwnode, port_num);
> + mux_desc.name = name;
> + mux_desc.set = mux_set;
> +
> + port_data->typec_mux = typec_mux_register(dev, _desc);
> + if (IS_ERR(port_data->typec_mux)) {
> + ret = PTR_ERR(port_data->typec_mux);
> + dev_err(dev, "Mode switch register for port %d failed: %d\n",
> + port_num, ret);
> +
> + return ret;
you don't need this return here...
> + }
> +
> + return 0;
Just "return ret;" here.
> +}
> +
> +/**
> + * drm_dp_register_typec_switches() - register Type-C switches
> + * @dev: Device that registers Type-C switches
> + * @port: Device node for the switch
> + * @switch_desc: A Type-C switch descriptor
> + * @data: Private data for the switches
> + * @mux_set: Callback function for typec_mux_set
> + *
> + * This function registers USB Type-C switches for DP bridges that can switch
> + * the output signal between their output pins.
> + *
> + * Currently only mode switches are implemented, and the function assumes the
> + * given @port device node has endpoints with "mode-switch" property.
> + * The port number is determined by the "reg" property of the endpoint.
> + */
> +int drm_dp_register_typec_switches(struct device *dev, struct fwnode_handle
> *port,
> +struct drm_dp_typec_switch_desc *switch_desc,
> +void *data, typec_mux_set_fn_t mux_set)
> +{
> + struct fwnode_handle *sw;
> + int ret;
> +
> + fwnode_for_each_child_node(port, sw) {
> + if (fwnode_property_present(sw, "mode-switch"))
> + switch_desc->num_typec_switches++;
> + }
no need for brackets here
> +
> + if (!switch_desc->num_typec_switches) {
> + dev_dbg(dev, "No Type-C switches node found\n");
dev_warn()?
> + return 0;
> + }
> +
> + switch_desc->typec_ports = devm_kcalloc(
> + dev, switch_desc->num_typec_switches,
> + sizeof(struct drm_dp_typec_port_data), GFP_KERNEL);
> +
> + if (!switch_desc->typec_ports)
> + return -ENOMEM;
> +
> + /* Register switches for each connector. */
> + fwnode_for_each_child_node(port, sw) {
> + if (!fwnode_property_present(sw, "mode-switch"))
> + continue;
> + ret = drm_dp_register_mode_switch(dev, sw, switch_desc, data,
> mux_set);
> + if (ret)
> + goto err_unregister_typec_switches;
> + }
> +
> + return 0;
> +
> +err_unregister_typec_switches:
> + fwnode_handle_put(sw);
> + drm_dp_unregister_typec_switches(switch_desc);
> + dev_err(dev, "Failed to register mode switch: %d\n", ret);
there is a bit of dmesg spamming. Please choose where you want to
print the error, either in this function or in
drm_dp_register_mode_switch().
Andi
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_dp_register_typec_switches);
[...]
Re: [PATCH] dt-bindings: display: panel: visionox,vtdr6130: add missing reg property
On Tue, Feb 07, 2023 at 02:37:16PM -0600, Rob Herring wrote:
> On Tue, Feb 07, 2023 at 07:36:00PM +0100, Sam Ravnborg wrote:
> > Hi Neil.
> >
> >
> > On Tue, Feb 07, 2023 at 11:04:36AM +0100, Neil Armstrong wrote:
> > > Add missing reg property and update example to add dsi top node.
> > >
> > > Fixes: ef85db911134 ("dt-bindings: display: panel: document the Visionox
> > > VTDR6130 AMOLED DSI Panel")
> > > Signed-off-by: Neil Armstrong
> > > ---
> > > .../bindings/display/panel/visionox,vtdr6130.yaml | 34
> > > ++
> > > 1 file changed, 22 insertions(+), 12 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > > b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > > index 49e2fd4b4e99..84562a5b710a 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > > +++
> > > b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > > @@ -16,6 +16,10 @@ properties:
> > >compatible:
> > > const: visionox,vtdr6130
> > >
> > > + reg:
> > > +maxItems: 1
> > > +description: DSI virtual channel
> > > +
> > Other panels using dsi uses a simple
> > " reg: true"
> >
> > I think that would suffice here too.
>
> Yes, because dsi-controller.yaml restricts it to a single entry.
> However, it's description says there can be more than 1 virtual channel
> for a device. In that case, it shouldn't be restricted in
> dsi-controller.yaml and the above with 'maxItems: 1' would be correct.
> So I'd keep this as-is.
Thanks for the explanation.
>
> Acked-by: Rob Herring
Acked-by: Sam Ravnborg
Re: [PATCH v3 24/27] drm/msm/dpu: rework plane CSC setting
On 2/7/2023 12:44 PM, Dmitry Baryshkov wrote:
On Tue, 7 Feb 2023 at 22:05, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +--
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index e69499490d39..05047192cb37 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -576,29 +576,18 @@ static const struct dpu_csc_cfg dpu_csc10_YUV2RGB_601L = {
{ 0x00, 0x3ff, 0x00, 0x3ff, 0x00, 0x3ff,},
};
-static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_plane *pdpu,
const struct dpu_format *fmt)
+static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_sw_pipe *pipe,
const struct dpu_format *fmt)
{
- struct dpu_plane_state *pstate = to_dpu_plane_state(pdpu->base.state);
const struct dpu_csc_cfg *csc_ptr;
- if (!pdpu) {
- DPU_ERROR("invalid plane\n");
- return NULL;
- }
-
if (!DPU_FORMAT_IS_YUV(fmt))
return NULL;
- if (BIT(DPU_SSPP_CSC_10BIT) & pstate->pipe.sspp->cap->features)
+ if (BIT(DPU_SSPP_CSC_10BIT) & pipe->sspp->cap->features)
csc_ptr = _csc10_YUV2RGB_601L;
else
csc_ptr = _csc_YUV2RGB_601L;
- DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
- csc_ptr->csc_mv[0],
- csc_ptr->csc_mv[1],
- csc_ptr->csc_mv[2]);
-
return csc_ptr;
}
@@ -1049,6 +1038,27 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
return 0;
}
+static void dpu_plane_flush_csc(struct dpu_plane *pdpu, struct dpu_sw_pipe
*pipe)
+{
+ const struct dpu_format *format =
to_dpu_format(msm_framebuffer_format(pdpu->base.state->fb));
+ const struct dpu_csc_cfg *csc_ptr;
+
+ if (!pipe->sspp || !pipe->sspp->ops.setup_csc)
+ return;
+
+ csc_ptr = _dpu_plane_get_csc(pipe, format);
+ if (!csc_ptr)
+ return;
+
+ DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
+ csc_ptr->csc_mv[0],
+ csc_ptr->csc_mv[1],
+ csc_ptr->csc_mv[2]);
+
+ pipe->sspp->ops.setup_csc(pipe->sspp, csc_ptr);
+
+}
+
void dpu_plane_flush(struct drm_plane *plane)
{
struct dpu_plane *pdpu;
@@ -1072,13 +1082,8 @@ void dpu_plane_flush(struct drm_plane *plane)
else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
/* force 100% alpha */
_dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
- else if (pstate->pipe.sspp && pstate->pipe.sspp->ops.setup_csc) {
- const struct dpu_format *fmt =
to_dpu_format(msm_framebuffer_format(plane->state->fb));
- const struct dpu_csc_cfg *csc_ptr = _dpu_plane_get_csc(pdpu, fmt);
-
- if (csc_ptr)
- pstate->pipe.sspp->ops.setup_csc(pstate->pipe.sspp,
csc_ptr);
- }
Do we need to check for pipe being valid too (pstate->pipe) &&
(pstate->pipe.sspp) && pstate->pipe.sspp->ops.setup_csc) ?
Before moving the pipe_hw/sw pipe to the state the code used to check
for pdpu->pipe_hw to be valid. Since dpu_plane_flush() can be called
from other files too , dont we need to check for (pstate->pipe)?
pstate->pipe is not a pointer, there is nothing to check.
Ah my bad. Only pipe.sspp is a pointer which you are already checking.
In that case,
Reviewed-by: Abhinav Kumar
+ else
+ dpu_plane_flush_csc(pdpu, >pipe);
/* flag h/w flush complete */
if (plane->state)
Re: [PATCH v11 7/9] dt-bindings: display: bridge: it6505: Add mode-switch support
On Sat, Feb 04, 2023 at 09:30:38PM +0800, Pin-yen Lin wrote: > ITE IT6505 can be used in systems to switch the DP traffic between > two downstreams, which can be USB Type-C DisplayPort alternate mode > lane or regular DisplayPort output ports. > > Update the binding to accommodate this usage by introducing a > data-lanes and a mode-switch property on endpoints. > > Signed-off-by: Pin-yen Lin > > --- > > Changes in v11: > - Updated the description of the endpoints in the bindings > - Referenced video-interfaces.yaml instead for the endpoints binding > - Removed duplicated definitions from inherited schema > > Changes in v9: > - Fixed subject prefix again > - Changed the naming of the example node for it6505 > > Changes in v8: > - Updated bindings for data-lanes property > - Fixed subject prefix > > Changes in v7: > - Fixed issues reported by dt_binding_check. > - Updated the schema and the example dts for data-lanes. > - Changed to generic naming for the example dts node. > > Changes in v6: > - Remove switches node and use endpoints and data-lanes property to > describe the connections. > > .../bindings/display/bridge/ite,it6505.yaml | 101 +++--- > 1 file changed, 88 insertions(+), 13 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > index b16a9d9127dd..8ae9c5cba22c 100644 > --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > @@ -75,22 +75,49 @@ properties: >port@1: > $ref: /schemas/graph.yaml#/$defs/port-base > unevaluatedProperties: false > -description: Video port for DP output > +description: > + Video port for DP output. Each endpoint connects to a video output > + downstream, and the "data-lanes" property is used to describe the > pin > + connections. 0, 1, 2, 3 in "data-lanes" maps to TX0, TX1, TX2, TX3, > + respectively. > > -properties: > - endpoint: > -$ref: /schemas/graph.yaml#/$defs/endpoint-base > + > +patternProperties: > + "^endpoint@[01]$": > +$ref: /schemas/media/video-interfaces.yaml# > unevaluatedProperties: false > > properties: > + reg: true > + > + remote-endpoint: true > + >data-lanes: > -minItems: 1 > -uniqueItems: true > -items: > - - enum: [ 0, 1 ] > - - const: 1 > - - const: 2 > - - const: 3 > +oneOf: > + - items: > + - enum: [0, 1, 2, 3] > + > + - items: > + - const: 0 > + - const: 1 > + > + - items: > + - const: 2 > + - const: 3 > + > + - items: > + - const: 0 > + - const: 1 > + - const: 2 > + - const: 3 > + > + mode-switch: > +type: boolean > +description: Register this node as a Type-C mode switch or > not. Existing users put this property in the device's node, not the endpoint. That seems more like a property of the device, than the DP link. You are using fwnode_typec_mux_get(), right? Rob
Re: [PATCH v3 24/27] drm/msm/dpu: rework plane CSC setting
On Tue, 7 Feb 2023 at 22:05, Abhinav Kumar wrote:
>
>
>
> On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
> > Rework the code flushing CSC settings for the plane. Separate out the
> > pipe and pipe_cfg as a preparation for r_pipe support.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +--
> > 1 file changed, 25 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index e69499490d39..05047192cb37 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -576,29 +576,18 @@ static const struct dpu_csc_cfg
> > dpu_csc10_YUV2RGB_601L = {
> > { 0x00, 0x3ff, 0x00, 0x3ff, 0x00, 0x3ff,},
> > };
> >
> > -static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_plane
> > *pdpu, const struct dpu_format *fmt)
> > +static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_sw_pipe
> > *pipe, const struct dpu_format *fmt)
> > {
> > - struct dpu_plane_state *pstate = to_dpu_plane_state(pdpu->base.state);
> > const struct dpu_csc_cfg *csc_ptr;
> >
> > - if (!pdpu) {
> > - DPU_ERROR("invalid plane\n");
> > - return NULL;
> > - }
> > -
> > if (!DPU_FORMAT_IS_YUV(fmt))
> > return NULL;
> >
> > - if (BIT(DPU_SSPP_CSC_10BIT) & pstate->pipe.sspp->cap->features)
> > + if (BIT(DPU_SSPP_CSC_10BIT) & pipe->sspp->cap->features)
> > csc_ptr = _csc10_YUV2RGB_601L;
> > else
> > csc_ptr = _csc_YUV2RGB_601L;
> >
> > - DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
> > - csc_ptr->csc_mv[0],
> > - csc_ptr->csc_mv[1],
> > - csc_ptr->csc_mv[2]);
> > -
> > return csc_ptr;
> > }
> >
> > @@ -1049,6 +1038,27 @@ static int dpu_plane_atomic_check(struct drm_plane
> > *plane,
> > return 0;
> > }
> >
> > +static void dpu_plane_flush_csc(struct dpu_plane *pdpu, struct dpu_sw_pipe
> > *pipe)
> > +{
> > + const struct dpu_format *format =
> > to_dpu_format(msm_framebuffer_format(pdpu->base.state->fb));
> > + const struct dpu_csc_cfg *csc_ptr;
> > +
> > + if (!pipe->sspp || !pipe->sspp->ops.setup_csc)
> > + return;
> > +
> > + csc_ptr = _dpu_plane_get_csc(pipe, format);
> > + if (!csc_ptr)
> > + return;
> > +
> > + DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
> > + csc_ptr->csc_mv[0],
> > + csc_ptr->csc_mv[1],
> > + csc_ptr->csc_mv[2]);
> > +
> > + pipe->sspp->ops.setup_csc(pipe->sspp, csc_ptr);
> > +
> > +}
> > +
> > void dpu_plane_flush(struct drm_plane *plane)
> > {
> > struct dpu_plane *pdpu;
> > @@ -1072,13 +1082,8 @@ void dpu_plane_flush(struct drm_plane *plane)
> > else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
> > /* force 100% alpha */
> > _dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
> > - else if (pstate->pipe.sspp && pstate->pipe.sspp->ops.setup_csc) {
> > - const struct dpu_format *fmt =
> > to_dpu_format(msm_framebuffer_format(plane->state->fb));
> > - const struct dpu_csc_cfg *csc_ptr = _dpu_plane_get_csc(pdpu,
> > fmt);
> > -
> > - if (csc_ptr)
> > - pstate->pipe.sspp->ops.setup_csc(pstate->pipe.sspp,
> > csc_ptr);
> > - }
>
> Do we need to check for pipe being valid too (pstate->pipe) &&
> (pstate->pipe.sspp) && pstate->pipe.sspp->ops.setup_csc) ?
>
> Before moving the pipe_hw/sw pipe to the state the code used to check
> for pdpu->pipe_hw to be valid. Since dpu_plane_flush() can be called
> from other files too , dont we need to check for (pstate->pipe)?
pstate->pipe is not a pointer, there is nothing to check.
>
> > + else
> > + dpu_plane_flush_csc(pdpu, >pipe);
> >
> > /* flag h/w flush complete */
> > if (plane->state)
--
With best wishes
Dmitry
Re: [PATCH v2 3/8] dt-bindings: display/msm/gmu: add Adreno 660 support
On Mon, 06 Feb 2023 16:57:02 +0200, Dmitry Baryshkov wrote: > Add Adreno A660 to the A635 clause to define all version-specific > properties. There is no need to add it to the top-level clause, since > top-level compatible uses pattern to define compatible strings. > > Signed-off-by: Dmitry Baryshkov > --- > Documentation/devicetree/bindings/display/msm/gmu.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2 1/8] dt-bindings: clock: Merge qcom,gpucc-sm8350 into qcom,gpucc.yaml
On Mon, 06 Feb 2023 16:57:00 +0200, Dmitry Baryshkov wrote: > The GPU clock controller bindings for the Qualcomm sm8350 platform are > not correct. The driver uses .fw_name instead of using indices to bind > parent clocks, thus demanding the clock-names usage. With the proper > clock-names in place, the bindings becomes equal to the bindings defined > by qcom,gpucc.yaml, so it is impractical to keep them in a separate > file. > > Signed-off-by: Dmitry Baryshkov > --- > .../bindings/clock/qcom,gpucc-sm8350.yaml | 71 --- > .../devicetree/bindings/clock/qcom,gpucc.yaml | 2 + > 2 files changed, 2 insertions(+), 71 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml > Acked-by: Rob Herring
Re: [PATCH] dt-bindings: display: panel: visionox,vtdr6130: add missing reg property
On Tue, Feb 07, 2023 at 07:36:00PM +0100, Sam Ravnborg wrote:
> Hi Neil.
>
>
> On Tue, Feb 07, 2023 at 11:04:36AM +0100, Neil Armstrong wrote:
> > Add missing reg property and update example to add dsi top node.
> >
> > Fixes: ef85db911134 ("dt-bindings: display: panel: document the Visionox
> > VTDR6130 AMOLED DSI Panel")
> > Signed-off-by: Neil Armstrong
> > ---
> > .../bindings/display/panel/visionox,vtdr6130.yaml | 34
> > ++
> > 1 file changed, 22 insertions(+), 12 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > index 49e2fd4b4e99..84562a5b710a 100644
> > --- a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> > @@ -16,6 +16,10 @@ properties:
> >compatible:
> > const: visionox,vtdr6130
> >
> > + reg:
> > +maxItems: 1
> > +description: DSI virtual channel
> > +
> Other panels using dsi uses a simple
> " reg: true"
>
> I think that would suffice here too.
Yes, because dsi-controller.yaml restricts it to a single entry.
However, it's description says there can be more than 1 virtual channel
for a device. In that case, it shouldn't be restricted in
dsi-controller.yaml and the above with 'maxItems: 1' would be correct.
So I'd keep this as-is.
Acked-by: Rob Herring
Rob
Re: [PATCH 3/4] drm/i915/xehp: LNCF/LBCF workarounds should be on the GT list
On Wed, Feb 01, 2023 at 02:28:30PM -0800, Matt Roper wrote:
> Although registers in the L3 bank/node configuration ranges are marked
> as having "DEV" reset characteristics in the bspec, this appears to be a
> hold-over from pre-Xe_HP platforms. In reality, these registers
> maintain their values across engine resets, meaning that workarounds
> and tuning settings targetting them should be placed on the GT
> workaround list rather than an engine workaround list.
>
> Note that an extra clue here is that these registers moved from the
> RENDER forcewake domain to the GT forcewake domain in Xe_HP; generally
> RCS/CCS engine resets should not lead to the reset of a register that
> lives outside the RENDER domain.
Looked and it seems DG2 also has GT forcewake domain for XEHP_L3NODEARBCFG.
Shouldn't Wa_14010648519 be fixed as well then? Or am I missing
something?
>
> Re-applying these registers on engine resets wouldn't actually hurt
> anything, but is unnecessary and just makes it more confusing to anyone
> trying to decipher how these registers really work.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 61 +
> 1 file changed, 38 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 7e93ba6b3208..09c9837458b5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1499,6 +1499,12 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> /* Wa_1409757795:xehpsdv */
> wa_mcr_write_or(wal, SCCGCTL94DC, CG3DDISURB);
>
> + /* Wa_18011725039:xehpsdv */
> + if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A1, STEP_B0)) {
> + wa_mcr_masked_dis(wal, MLTICTXCTL, TDONRENDER);
> + wa_mcr_write_or(wal, L3SQCREG1_CCS0, FLUSHALLNONCOH);
> + }
> +
> /* Wa_16011155590:xehpsdv */
> if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A0, STEP_B0))
> wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
> @@ -1548,6 +1554,9 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> /* Wa_14014368820:xehpsdv */
> wa_mcr_write_or(wal, XEHP_GAMCNTRL_CTRL,
> INVALIDATION_BROADCAST_MODE_DIS |
> GLOBAL_INVALIDATION_MODE);
> +
> + /* Wa_14010670810:xehpsdv */
> + wa_mcr_write_or(wal, XEHP_L3NODEARBCFG, XEHP_LNESPARE);
> }
>
> static void
> @@ -1684,6 +1693,9 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, XEHP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, XEHP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
> +
> + /* Wa_16016694945 */
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
> }
>
> static void
> @@ -1724,11 +1736,36 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> debug_dump_steering(gt);
> }
>
> +/*
> + * The bspec performance guide has recommended MMIO tuning settings. These
> + * aren't truly "workarounds" but we want to program them through the
> + * workaround infrastructure to make sure they're (re)applied at the proper
> + * times.
> + *
> + * The settings in this function are for settings that persist through
> + * engine resets and also are not part of any engine's register state
> context.
> + * I.e., settings that only need to be re-applied in the event of a full GT
> + * reset.
> + */
> +static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list *wal)
> +{
> + if (IS_PONTEVECCHIO(gt->i915)) {
> + wa_mcr_write(wal, XEHPC_L3SCRUB,
> + SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> + }
> +
> + if (IS_DG2(gt->i915))
> + wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> +}
> +
> static void
> gt_init_workarounds(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = gt->i915;
>
> + gt_tuning_settings(gt, wal);
> +
> if (gt->type == GT_MEDIA) {
> if (MEDIA_VER(i915) >= 13)
> xelpmp_gt_workarounds_init(gt, wal);
> @@ -2897,16 +2934,8 @@ static void
> add_render_compute_tuning_settings(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> {
> - if (IS_PONTEVECCHIO(i915)) {
> - wa_mcr_write(wal, XEHPC_L3SCRUB,
> - SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
> - wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> - }
> -
> - if (IS_DG2(i915)) {
> - wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> + if (IS_DG2(i915))
> wa_mcr_write_clr_set(wal,
Re: [PATCH v3 24/27] drm/msm/dpu: rework plane CSC setting
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +--
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index e69499490d39..05047192cb37 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -576,29 +576,18 @@ static const struct dpu_csc_cfg dpu_csc10_YUV2RGB_601L = {
{ 0x00, 0x3ff, 0x00, 0x3ff, 0x00, 0x3ff,},
};
-static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_plane *pdpu, const struct dpu_format *fmt)
+static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_sw_pipe *pipe,
const struct dpu_format *fmt)
{
- struct dpu_plane_state *pstate = to_dpu_plane_state(pdpu->base.state);
const struct dpu_csc_cfg *csc_ptr;
- if (!pdpu) {
- DPU_ERROR("invalid plane\n");
- return NULL;
- }
-
if (!DPU_FORMAT_IS_YUV(fmt))
return NULL;
- if (BIT(DPU_SSPP_CSC_10BIT) & pstate->pipe.sspp->cap->features)
+ if (BIT(DPU_SSPP_CSC_10BIT) & pipe->sspp->cap->features)
csc_ptr = _csc10_YUV2RGB_601L;
else
csc_ptr = _csc_YUV2RGB_601L;
- DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
- csc_ptr->csc_mv[0],
- csc_ptr->csc_mv[1],
- csc_ptr->csc_mv[2]);
-
return csc_ptr;
}
@@ -1049,6 +1038,27 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return 0;
}
+static void dpu_plane_flush_csc(struct dpu_plane *pdpu, struct dpu_sw_pipe *pipe)
+{
+ const struct dpu_format *format =
to_dpu_format(msm_framebuffer_format(pdpu->base.state->fb));
+ const struct dpu_csc_cfg *csc_ptr;
+
+ if (!pipe->sspp || !pipe->sspp->ops.setup_csc)
+ return;
+
+ csc_ptr = _dpu_plane_get_csc(pipe, format);
+ if (!csc_ptr)
+ return;
+
+ DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
+ csc_ptr->csc_mv[0],
+ csc_ptr->csc_mv[1],
+ csc_ptr->csc_mv[2]);
+
+ pipe->sspp->ops.setup_csc(pipe->sspp, csc_ptr);
+
+}
+
void dpu_plane_flush(struct drm_plane *plane)
{
struct dpu_plane *pdpu;
@@ -1072,13 +1082,8 @@ void dpu_plane_flush(struct drm_plane *plane)
else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
/* force 100% alpha */
_dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
- else if (pstate->pipe.sspp && pstate->pipe.sspp->ops.setup_csc) {
- const struct dpu_format *fmt =
to_dpu_format(msm_framebuffer_format(plane->state->fb));
- const struct dpu_csc_cfg *csc_ptr = _dpu_plane_get_csc(pdpu,
fmt);
-
- if (csc_ptr)
- pstate->pipe.sspp->ops.setup_csc(pstate->pipe.sspp,
csc_ptr);
- }
Do we need to check for pipe being valid too (pstate->pipe) &&
(pstate->pipe.sspp) && pstate->pipe.sspp->ops.setup_csc) ?
Before moving the pipe_hw/sw pipe to the state the code used to check
for pdpu->pipe_hw to be valid. Since dpu_plane_flush() can be called
from other files too , dont we need to check for (pstate->pipe)?
+ else
+ dpu_plane_flush_csc(pdpu, >pipe);
/* flag h/w flush complete */
if (plane->state)
Re: [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check()
On 07/02/2023 20:08, Abhinav Kumar wrote:
On 2/7/2023 9:59 AM, Dmitry Baryshkov wrote:
On 07/02/2023 19:57, Abhinav Kumar wrote:
On 2/7/2023 9:51 AM, Dmitry Baryshkov wrote:
On 07/02/2023 19:49, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
Same comment as prev patch, dpu_plane_atomic_check_pipe() --->
dpu_plane_atomic_check_sspp()
No, it does what it does: it checks one software pipe configuration.
The concept of software pipe is only to encapsulate the hw_sspp along
with its params
+struct dpu_sw_pipe {
+ struct dpu_hw_sspp *sspp;
+ enum dpu_sspp_multirect_index multirect_index;
+ enum dpu_sspp_multirect_mode multirect_mode;
+};
So its a very thin differentiation there.
SSPP is a hardware thing, while the sw_pipe is a software instance. It
can employ an SSPP or a half of SSPP. And if it employs a half of SSPP
(rec1) than the name dpu_plane_atomic_check_sspp() doesn't make sense:
we are not checking the SSPP itself (or its configuration). We are
checking the parameters of SW pipe.
Ok, I need to check in the next couple of patches how you are handling
the same dpu_sw_pipe for different rects of the same sspp.
rec0 and rec1 are two different instances of dpu_sw_pipe
struct dpu_plane_state {
struct drm_plane_state base;
struct msm_gem_address_space *aspace;
- struct dpu_hw_sspp *hw_sspp;
+ struct dpu_sw_pipe pipe;
enum dpu_stage stage;
bool needs_qos_remap;
- uint32_t multirect_index;
So far what I saw was dpu_plane_state ---> dpu_sw_pipe ---> dpu_hw_sppp
In this chain, I couldnt get how the two rects of the DMA SSPP are
differentiated, perhaps there is something in the next few changes.
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88
++-
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f94e132733f3..e69499490d39 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -903,6 +903,51 @@ static int
dpu_plane_check_inline_rotation(struct dpu_plane *pdpu,
return 0;
}
+static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
pipe_cfg --> sspp_cfg
Also, had a question. For function parameters spreading across
multiple lines do we want to align to one guideline? Is it going to
be two tabs more than the prev line or aligning it with the opening
brace of prev line?
I am seeing a mix in the prev patch of the series and this one.
I usually tend to keep the existing indent when adding new args and
shifting to open brace when adding new functions. Maybe I failed a
question in this patch, I'll doublecheck it.
+ const struct dpu_format *fmt)
+{
+ uint32_t min_src_size;
+
+ min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
+
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (!(pipe->sspp->cap->features & DPU_SSPP_SCALER) ||
+ !(pipe->sspp->cap->features & DPU_SSPP_CSC_ANY))) {
+ DPU_DEBUG_PLANE(pdpu,
+ "plane doesn't have scaler/csc for yuv\n");
+ return -EINVAL;
+ }
+
+ /* check src bounds */
+ if (drm_rect_width(_cfg->src_rect) < min_src_size ||
+ drm_rect_height(_cfg->src_rect) < min_src_size) {
+ DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -E2BIG;
+ }
+
+ /* valid yuv image */
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1
& 0x1 ||
+ drm_rect_width(_cfg->src_rect) & 0x1 ||
+ drm_rect_height(_cfg->src_rect) & 0x1)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT
"\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -EINVAL;
+ }
+
+ /* min dst support */
+ if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
+ DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT
"\n",
+ DRM_RECT_ARG(_cfg->dst_rect));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -915,7 +960,7 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
struct drm_rect fb_rect = { 0 };
- uint32_t min_src_size, max_linewidth;
+ uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps =
pstate->pipe.sspp->cap;
@@
Re: [Intel-gfx] [PATCH 2/4] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list
On Wed, Feb 01, 2023 at 02:28:29PM -0800, Matt Roper wrote:
> The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround
> has 'BUS' style reset, indicating that it does not lose its value on
> engine resets. Furthermore, this register is part of the GT forcewake
> domain rather than the RENDER domain, so it should not be impacted by
> RCS engine resets. As such, we should implement this on the GT
> workaround list rather than an engine list.
>
> Bspec: 19219
> Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()")
> Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index f45ca3d4a07c..7e93ba6b3208 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1405,6 +1405,13 @@ icl_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> GAMT_CHKN_BIT_REG,
> GAMT_CHKN_DISABLE_L3_COH_PIPE);
>
> + /*
> + * Wa_1408615072:icl,ehl (vsunit)
> + * Wa_1407596294:icl,ehl (hsunit)
> + */
> + wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
> + VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
> +
> /* Wa_1407352427:icl,ehl */
> wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
> PSDUNIT_CLKGATE_DIS);
> @@ -2536,13 +2543,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> wa_masked_en(wal, GEN9_CSFE_CHICKEN1_RCS,
>GEN11_ENABLE_32_PLANE_MODE);
>
> - /*
> - * Wa_1408615072:icl,ehl (vsunit)
> - * Wa_1407596294:icl,ehl (hsunit)
> - */
> - wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
> - VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
> -
> /*
>* Wa_1408767742:icl[a2..forever],ehl[all]
>* Wa_1605460711:icl[a0..c0]
> --
> 2.39.1
>
Re: [PATCH] drm/i915/hwmon: Enable PL1 power limit
On Tue, 7 Feb 2023 at 17:19, Dixit, Ashutosh wrote:
>
> On Tue, 07 Feb 2023 08:12:25 -0800, Dixit, Ashutosh wrote:
> >
> > On Tue, 07 Feb 2023 01:32:44 -0800, Matthew Auld wrote:
> > >
> > > On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit
> > > wrote:
> > > >
> > > > Previous documentation suggested that PL1 power limit is always
> > > > enabled. However we now find this not to be the case on some
> > > > platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> > > > initialization.
> > >
> > > For some reason it looks like this change is impacting the atsm in CI:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
> >
> > Hmm, the change was meant for ATSM. Anyway let me try to get hold of an
> > ATSM and see if I can figure out what might be going on with these
> > seemingly unrelated failures and if I can repro them locally. Thanks!
>
> Rodrigo/Matt,
>
> I am proposing we revert this now and remerge again after investigating,
> even getting ATSM systems to investigate is not easy so it might take a few
> days to investigate. What do you guys think?
Yeah, maybe just revert for now.
>
> Thanks.
> --
> Ashutosh
>
>
> >
> > >
> > > >
> > > > Bspec: 51864
> > > >
> > > > v2: Add Bspec reference (Gwan-gyeong)
> > > > v3: Add Fixes tag
> > > >
> > > > Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > > Signed-off-by: Ashutosh Dixit
> > > > Reviewed-by: Gwan-gyeong Mun
> > > > ---
> > > > drivers/gpu/drm/i915/i915_hwmon.c | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > index 1225bc432f0d5..4683a5b96eff1 100644
> > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct
> > > > drm_i915_private *i915)
> > > > for_each_gt(gt, i915, i)
> > > > hwm_energy(>ddat_gt[i], );
> > > > }
> > > > +
> > > > + /* Enable PL1 power limit */
> > > > + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > > > + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> > > > hwmon->rg.pkg_rapl_limit,
> > > > + PKG_PWR_LIM_1_EN,
> > > > PKG_PWR_LIM_1_EN);
> > > > }
> > > >
> > > > void i915_hwmon_register(struct drm_i915_private *i915)
> > > > --
> > > > 2.38.0
> > > >
Re: [PATCH] dt-bindings: display: panel: visionox,vtdr6130: add missing reg property
Hi Neil.
On Tue, Feb 07, 2023 at 11:04:36AM +0100, Neil Armstrong wrote:
> Add missing reg property and update example to add dsi top node.
>
> Fixes: ef85db911134 ("dt-bindings: display: panel: document the Visionox
> VTDR6130 AMOLED DSI Panel")
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/panel/visionox,vtdr6130.yaml | 34
> ++
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> index 49e2fd4b4e99..84562a5b710a 100644
> --- a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
> @@ -16,6 +16,10 @@ properties:
>compatible:
> const: visionox,vtdr6130
>
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
Other panels using dsi uses a simple
" reg: true"
I think that would suffice here too.
Sam
Re: [Intel-gfx] [PATCH 1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR
On Wed, Feb 01, 2023 at 02:28:28PM -0800, Matt Roper wrote:
> XEHPC_LNCFMISCCFGREG0 and XEHPC_L3SCRUB are both in MCR register ranges
> on PVC (with HALFBSLICE and L3BANK replication respectively), so they
> should be explicitly declared as MCR registers and use MCR-aware
> workaround handlers.
>
> The workarounds/tuning settings should still be applied properly on PVC
> even without the MCR annotation, but readback verification on
> CONFIG_DRM_I915_DEBUG_GEM builds could potentitally give false positive
> "workaround lost on load" warnings on parts fused such that a unicast
> read targets a terminated register instance.
>
> Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
> Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +---
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 7fa18a3b3957..928698c621e5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -979,7 +979,7 @@
> #define GEN7_WA_FOR_GEN7_L3_CONTROL0x3C47FF8C
> #define GEN7_L3AGDIS (1 << 19)
>
> -#define XEHPC_LNCFMISCCFGREG0_MMIO(0xb01c)
> +#define XEHPC_LNCFMISCCFGREG0MCR_REG(0xb01c)
> #define XEHPC_HOSTCACHEEN REG_BIT(1)
> #define XEHPC_OVRLSCCC REG_BIT(0)
>
> @@ -1042,7 +1042,7 @@
> #define XEHP_L3SCQREG7 MCR_REG(0xb188)
> #define BLEND_FILL_CACHING_OPT_DIS REG_BIT(3)
>
> -#define XEHPC_L3SCRUB_MMIO(0xb18c)
> +#define XEHPC_L3SCRUBMCR_REG(0xb18c)
> #define SCRUB_CL_DWNGRADE_SHARED REG_BIT(12)
> #define SCRUB_RATE_PER_BANK_MASK REG_GENMASK(2, 0)
> #define SCRUB_RATE_4B_PER_CLK
> REG_FIELD_PREP(SCRUB_RATE_PER_BANK_MASK, 0x6)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 29718d0595f4..f45ca3d4a07c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -240,6 +240,12 @@ wa_write(struct i915_wa_list *wal, i915_reg_t reg, u32
> set)
> wa_write_clr_set(wal, reg, ~0, set);
> }
>
> +static void
> +wa_mcr_write(struct i915_wa_list *wal, i915_mcr_reg_t reg, u32 set)
> +{
> + wa_mcr_write_clr_set(wal, reg, ~0, set);
> +}
> +
> static void
> wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
> {
> @@ -2892,9 +2898,9 @@ add_render_compute_tuning_settings(struct
> drm_i915_private *i915,
> struct i915_wa_list *wal)
> {
> if (IS_PONTEVECCHIO(i915)) {
> - wa_write(wal, XEHPC_L3SCRUB,
> + wa_mcr_write(wal, XEHPC_L3SCRUB,
>SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
> - wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> }
>
> if (IS_DG2(i915)) {
> @@ -2984,7 +2990,7 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
>
> if (IS_PONTEVECCHIO(i915)) {
> /* Wa_16016694945 */
> - wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
> }
>
> if (IS_XEHPSDV(i915)) {
> --
> 2.39.1
>
Re: [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check()
On 2/7/2023 9:59 AM, Dmitry Baryshkov wrote:
On 07/02/2023 19:57, Abhinav Kumar wrote:
On 2/7/2023 9:51 AM, Dmitry Baryshkov wrote:
On 07/02/2023 19:49, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
Same comment as prev patch, dpu_plane_atomic_check_pipe() --->
dpu_plane_atomic_check_sspp()
No, it does what it does: it checks one software pipe configuration.
The concept of software pipe is only to encapsulate the hw_sspp along
with its params
+struct dpu_sw_pipe {
+ struct dpu_hw_sspp *sspp;
+ enum dpu_sspp_multirect_index multirect_index;
+ enum dpu_sspp_multirect_mode multirect_mode;
+};
So its a very thin differentiation there.
SSPP is a hardware thing, while the sw_pipe is a software instance. It
can employ an SSPP or a half of SSPP. And if it employs a half of SSPP
(rec1) than the name dpu_plane_atomic_check_sspp() doesn't make sense:
we are not checking the SSPP itself (or its configuration). We are
checking the parameters of SW pipe.
Ok, I need to check in the next couple of patches how you are handling
the same dpu_sw_pipe for different rects of the same sspp.
struct dpu_plane_state {
struct drm_plane_state base;
struct msm_gem_address_space *aspace;
- struct dpu_hw_sspp *hw_sspp;
+ struct dpu_sw_pipe pipe;
enum dpu_stage stage;
bool needs_qos_remap;
- uint32_t multirect_index;
So far what I saw was dpu_plane_state ---> dpu_sw_pipe ---> dpu_hw_sppp
In this chain, I couldnt get how the two rects of the DMA SSPP are
differentiated, perhaps there is something in the next few changes.
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88
++-
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f94e132733f3..e69499490d39 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -903,6 +903,51 @@ static int
dpu_plane_check_inline_rotation(struct dpu_plane *pdpu,
return 0;
}
+static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
pipe_cfg --> sspp_cfg
Also, had a question. For function parameters spreading across
multiple lines do we want to align to one guideline? Is it going to
be two tabs more than the prev line or aligning it with the opening
brace of prev line?
I am seeing a mix in the prev patch of the series and this one.
I usually tend to keep the existing indent when adding new args and
shifting to open brace when adding new functions. Maybe I failed a
question in this patch, I'll doublecheck it.
+ const struct dpu_format *fmt)
+{
+ uint32_t min_src_size;
+
+ min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
+
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (!(pipe->sspp->cap->features & DPU_SSPP_SCALER) ||
+ !(pipe->sspp->cap->features & DPU_SSPP_CSC_ANY))) {
+ DPU_DEBUG_PLANE(pdpu,
+ "plane doesn't have scaler/csc for yuv\n");
+ return -EINVAL;
+ }
+
+ /* check src bounds */
+ if (drm_rect_width(_cfg->src_rect) < min_src_size ||
+ drm_rect_height(_cfg->src_rect) < min_src_size) {
+ DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -E2BIG;
+ }
+
+ /* valid yuv image */
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 &
0x1 ||
+ drm_rect_width(_cfg->src_rect) & 0x1 ||
+ drm_rect_height(_cfg->src_rect) & 0x1)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT
"\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -EINVAL;
+ }
+
+ /* min dst support */
+ if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
+ DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->dst_rect));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -915,7 +960,7 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
struct drm_rect fb_rect = { 0 };
- uint32_t min_src_size, max_linewidth;
+ uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps =
pstate->pipe.sspp->cap;
@@ -970,46 +1015,19 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
Re: [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check()
On 07/02/2023 19:57, Abhinav Kumar wrote:
On 2/7/2023 9:51 AM, Dmitry Baryshkov wrote:
On 07/02/2023 19:49, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
Same comment as prev patch, dpu_plane_atomic_check_pipe() --->
dpu_plane_atomic_check_sspp()
No, it does what it does: it checks one software pipe configuration.
The concept of software pipe is only to encapsulate the hw_sspp along
with its params
+struct dpu_sw_pipe {
+ struct dpu_hw_sspp *sspp;
+ enum dpu_sspp_multirect_index multirect_index;
+ enum dpu_sspp_multirect_mode multirect_mode;
+};
So its a very thin differentiation there.
SSPP is a hardware thing, while the sw_pipe is a software instance. It
can employ an SSPP or a half of SSPP. And if it employs a half of SSPP
(rec1) than the name dpu_plane_atomic_check_sspp() doesn't make sense:
we are not checking the SSPP itself (or its configuration). We are
checking the parameters of SW pipe.
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88
++-
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f94e132733f3..e69499490d39 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -903,6 +903,51 @@ static int
dpu_plane_check_inline_rotation(struct dpu_plane *pdpu,
return 0;
}
+static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
pipe_cfg --> sspp_cfg
Also, had a question. For function parameters spreading across
multiple lines do we want to align to one guideline? Is it going to
be two tabs more than the prev line or aligning it with the opening
brace of prev line?
I am seeing a mix in the prev patch of the series and this one.
I usually tend to keep the existing indent when adding new args and
shifting to open brace when adding new functions. Maybe I failed a
question in this patch, I'll doublecheck it.
+ const struct dpu_format *fmt)
+{
+ uint32_t min_src_size;
+
+ min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
+
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (!(pipe->sspp->cap->features & DPU_SSPP_SCALER) ||
+ !(pipe->sspp->cap->features & DPU_SSPP_CSC_ANY))) {
+ DPU_DEBUG_PLANE(pdpu,
+ "plane doesn't have scaler/csc for yuv\n");
+ return -EINVAL;
+ }
+
+ /* check src bounds */
+ if (drm_rect_width(_cfg->src_rect) < min_src_size ||
+ drm_rect_height(_cfg->src_rect) < min_src_size) {
+ DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -E2BIG;
+ }
+
+ /* valid yuv image */
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 &
0x1 ||
+ drm_rect_width(_cfg->src_rect) & 0x1 ||
+ drm_rect_height(_cfg->src_rect) & 0x1)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -EINVAL;
+ }
+
+ /* min dst support */
+ if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
+ DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->dst_rect));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -915,7 +960,7 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
struct drm_rect fb_rect = { 0 };
- uint32_t min_src_size, max_linewidth;
+ uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps = pstate->pipe.sspp->cap;
@@ -970,46 +1015,19 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
- fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
-
- min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
-
- if (DPU_FORMAT_IS_YUV(fmt) &&
- (!(pipe_hw_caps->features & DPU_SSPP_SCALER) ||
- !(pipe_hw_caps->features & DPU_SSPP_CSC_ANY))) {
- DPU_DEBUG_PLANE(pdpu,
- "plane doesn't have scaler/csc for yuv\n");
- return -EINVAL;
-
- /* check src bounds */
- } else if (drm_rect_width(_cfg->src_rect) < min_src_size ||
- drm_rect_height(_cfg->src_rect) < min_src_size) {
- DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
Re: [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check()
On 2/7/2023 9:51 AM, Dmitry Baryshkov wrote:
On 07/02/2023 19:49, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
Same comment as prev patch, dpu_plane_atomic_check_pipe() --->
dpu_plane_atomic_check_sspp()
No, it does what it does: it checks one software pipe configuration.
The concept of software pipe is only to encapsulate the hw_sspp along
with its params
+struct dpu_sw_pipe {
+ struct dpu_hw_sspp *sspp;
+ enum dpu_sspp_multirect_index multirect_index;
+ enum dpu_sspp_multirect_mode multirect_mode;
+};
So its a very thin differentiation there.
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88 ++-
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f94e132733f3..e69499490d39 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -903,6 +903,51 @@ static int
dpu_plane_check_inline_rotation(struct dpu_plane *pdpu,
return 0;
}
+static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
pipe_cfg --> sspp_cfg
Also, had a question. For function parameters spreading across
multiple lines do we want to align to one guideline? Is it going to be
two tabs more than the prev line or aligning it with the opening brace
of prev line?
I am seeing a mix in the prev patch of the series and this one.
I usually tend to keep the existing indent when adding new args and
shifting to open brace when adding new functions. Maybe I failed a
question in this patch, I'll doublecheck it.
+ const struct dpu_format *fmt)
+{
+ uint32_t min_src_size;
+
+ min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
+
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (!(pipe->sspp->cap->features & DPU_SSPP_SCALER) ||
+ !(pipe->sspp->cap->features & DPU_SSPP_CSC_ANY))) {
+ DPU_DEBUG_PLANE(pdpu,
+ "plane doesn't have scaler/csc for yuv\n");
+ return -EINVAL;
+ }
+
+ /* check src bounds */
+ if (drm_rect_width(_cfg->src_rect) < min_src_size ||
+ drm_rect_height(_cfg->src_rect) < min_src_size) {
+ DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -E2BIG;
+ }
+
+ /* valid yuv image */
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 &
0x1 ||
+ drm_rect_width(_cfg->src_rect) & 0x1 ||
+ drm_rect_height(_cfg->src_rect) & 0x1)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -EINVAL;
+ }
+
+ /* min dst support */
+ if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
+ DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->dst_rect));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -915,7 +960,7 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
struct drm_rect fb_rect = { 0 };
- uint32_t min_src_size, max_linewidth;
+ uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps = pstate->pipe.sspp->cap;
@@ -970,46 +1015,19 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
- fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
-
- min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
-
- if (DPU_FORMAT_IS_YUV(fmt) &&
- (!(pipe_hw_caps->features & DPU_SSPP_SCALER) ||
- !(pipe_hw_caps->features & DPU_SSPP_CSC_ANY))) {
- DPU_DEBUG_PLANE(pdpu,
- "plane doesn't have scaler/csc for yuv\n");
- return -EINVAL;
-
- /* check src bounds */
- } else if (drm_rect_width(_cfg->src_rect) < min_src_size ||
- drm_rect_height(_cfg->src_rect) < min_src_size) {
- DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(_cfg->src_rect));
- return -E2BIG;
-
- /* valid yuv image */
- } else if (DPU_FORMAT_IS_YUV(fmt) &&
- (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 &
0x1 ||
- drm_rect_width(_cfg->src_rect) & 0x1 ||
- drm_rect_height(_cfg->src_rect) & 0x1)) {
- DPU_DEBUG_PLANE(pdpu,
Re: [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check()
On 07/02/2023 19:49, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
Same comment as prev patch, dpu_plane_atomic_check_pipe() --->
dpu_plane_atomic_check_sspp()
No, it does what it does: it checks one software pipe configuration.
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88 ++-
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f94e132733f3..e69499490d39 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -903,6 +903,51 @@ static int dpu_plane_check_inline_rotation(struct
dpu_plane *pdpu,
return 0;
}
+static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
pipe_cfg --> sspp_cfg
Also, had a question. For function parameters spreading across multiple
lines do we want to align to one guideline? Is it going to be two tabs
more than the prev line or aligning it with the opening brace of prev line?
I am seeing a mix in the prev patch of the series and this one.
I usually tend to keep the existing indent when adding new args and
shifting to open brace when adding new functions. Maybe I failed a
question in this patch, I'll doublecheck it.
+ const struct dpu_format *fmt)
+{
+ uint32_t min_src_size;
+
+ min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
+
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (!(pipe->sspp->cap->features & DPU_SSPP_SCALER) ||
+ !(pipe->sspp->cap->features & DPU_SSPP_CSC_ANY))) {
+ DPU_DEBUG_PLANE(pdpu,
+ "plane doesn't have scaler/csc for yuv\n");
+ return -EINVAL;
+ }
+
+ /* check src bounds */
+ if (drm_rect_width(_cfg->src_rect) < min_src_size ||
+ drm_rect_height(_cfg->src_rect) < min_src_size) {
+ DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -E2BIG;
+ }
+
+ /* valid yuv image */
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 &
0x1 ||
+ drm_rect_width(_cfg->src_rect) & 0x1 ||
+ drm_rect_height(_cfg->src_rect) & 0x1)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -EINVAL;
+ }
+
+ /* min dst support */
+ if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
+ DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->dst_rect));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -915,7 +960,7 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
struct drm_rect fb_rect = { 0 };
- uint32_t min_src_size, max_linewidth;
+ uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps = pstate->pipe.sspp->cap;
@@ -970,46 +1015,19 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
- fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
-
- min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
-
- if (DPU_FORMAT_IS_YUV(fmt) &&
- (!(pipe_hw_caps->features & DPU_SSPP_SCALER) ||
- !(pipe_hw_caps->features & DPU_SSPP_CSC_ANY))) {
- DPU_DEBUG_PLANE(pdpu,
- "plane doesn't have scaler/csc for yuv\n");
- return -EINVAL;
-
- /* check src bounds */
- } else if (drm_rect_width(_cfg->src_rect) < min_src_size ||
- drm_rect_height(_cfg->src_rect) < min_src_size) {
- DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(_cfg->src_rect));
- return -E2BIG;
-
- /* valid yuv image */
- } else if (DPU_FORMAT_IS_YUV(fmt) &&
- (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 &
0x1 ||
- drm_rect_width(_cfg->src_rect) & 0x1 ||
- drm_rect_height(_cfg->src_rect) & 0x1)) {
- DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(_cfg->src_rect));
- return -EINVAL;
-
- /* min dst support */
- } else if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
- DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
-
Re: [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check()
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
Same comment as prev patch, dpu_plane_atomic_check_pipe() --->
dpu_plane_atomic_check_sspp()
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88 ++-
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f94e132733f3..e69499490d39 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -903,6 +903,51 @@ static int dpu_plane_check_inline_rotation(struct
dpu_plane *pdpu,
return 0;
}
+static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
pipe_cfg --> sspp_cfg
Also, had a question. For function parameters spreading across multiple
lines do we want to align to one guideline? Is it going to be two tabs
more than the prev line or aligning it with the opening brace of prev line?
I am seeing a mix in the prev patch of the series and this one.
+ const struct dpu_format *fmt)
+{
+ uint32_t min_src_size;
+
+ min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
+
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (!(pipe->sspp->cap->features & DPU_SSPP_SCALER) ||
+!(pipe->sspp->cap->features & DPU_SSPP_CSC_ANY))) {
+ DPU_DEBUG_PLANE(pdpu,
+ "plane doesn't have scaler/csc for yuv\n");
+ return -EINVAL;
+ }
+
+ /* check src bounds */
+ if (drm_rect_width(_cfg->src_rect) < min_src_size ||
+ drm_rect_height(_cfg->src_rect) < min_src_size) {
+ DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -E2BIG;
+ }
+
+ /* valid yuv image */
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 & 0x1
||
+ drm_rect_width(_cfg->src_rect) & 0x1 ||
+ drm_rect_height(_cfg->src_rect) & 0x1)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->src_rect));
+ return -EINVAL;
+ }
+
+ /* min dst support */
+ if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
+ DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(_cfg->dst_rect));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -915,7 +960,7 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
struct drm_rect fb_rect = { 0 };
- uint32_t min_src_size, max_linewidth;
+ uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps = pstate->pipe.sspp->cap;
@@ -970,46 +1015,19 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
- fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
-
- min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
-
- if (DPU_FORMAT_IS_YUV(fmt) &&
- (!(pipe_hw_caps->features & DPU_SSPP_SCALER) ||
-!(pipe_hw_caps->features & DPU_SSPP_CSC_ANY))) {
- DPU_DEBUG_PLANE(pdpu,
- "plane doesn't have scaler/csc for yuv\n");
- return -EINVAL;
-
- /* check src bounds */
- } else if (drm_rect_width(_cfg->src_rect) < min_src_size ||
- drm_rect_height(_cfg->src_rect) < min_src_size) {
- DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(_cfg->src_rect));
- return -E2BIG;
-
- /* valid yuv image */
- } else if (DPU_FORMAT_IS_YUV(fmt) &&
- (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 & 0x1
||
- drm_rect_width(_cfg->src_rect) & 0x1 ||
- drm_rect_height(_cfg->src_rect) & 0x1)) {
- DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(_cfg->src_rect));
- return -EINVAL;
-
- /* min dst support */
- } else if (drm_rect_width(_cfg->dst_rect) < 0x1 ||
drm_rect_height(_cfg->dst_rect) < 0x1) {
-
Re: [PATCH] drm: Disable dynamic debug as broken
On Tue, Feb 07, 2023 at 04:33:37PM +0200, Jani Nikula wrote:
> From: Ville Syrjälä
>
> CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular)
> drm drivers. The debug prints can be reinstated by manually frobbing
> /sys/module/drm/parameters/debug after the fact, but at that point the
> damage is done and all debugs from driver probe are lost. This makes
> drivers totally undebuggable.
>
> There's a more complete fix in progress [1], with further details, but
> we need this fixed in stable kernels. Mark the feature as broken and
> disable it by default, with hopes distros follow suit and disable it as
> well.
>
> [1] https://lore.kernel.org/r/20230125203743.564009-1-jim.cro...@gmail.com
>
> Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory
> macro")
> Cc: Jim Cromie
> Cc: Greg Kroah-Hartman
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: # v6.1+
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f42d4c6a19f2..dc0f94f02a82 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -52,7 +52,8 @@ config DRM_DEBUG_MM
>
> config DRM_USE_DYNAMIC_DEBUG
> bool "use dynamic debug to implement drm.debug"
> - default y
> + default n
> + depends on BROKEN
> depends on DRM
> depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> depends on JUMP_LABEL
Acked-by: Greg Kroah-Hartman
[PATCH] drm: Disable dynamic debug as broken
From: Ville Syrjälä
CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular)
drm drivers. The debug prints can be reinstated by manually frobbing
/sys/module/drm/parameters/debug after the fact, but at that point the
damage is done and all debugs from driver probe are lost. This makes
drivers totally undebuggable.
There's a more complete fix in progress [1], with further details, but
we need this fixed in stable kernels. Mark the feature as broken and
disable it by default, with hopes distros follow suit and disable it as
well.
[1] https://lore.kernel.org/r/20230125203743.564009-1-jim.cro...@gmail.com
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory
macro")
Cc: Jim Cromie
Cc: Greg Kroah-Hartman
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.1+
Signed-off-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f42d4c6a19f2..dc0f94f02a82 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -52,7 +52,8 @@ config DRM_DEBUG_MM
config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
- default y
+ default n
+ depends on BROKEN
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
--
2.34.1
Re: [PATCH] drm/i915/hwmon: Enable PL1 power limit
On Tue, 07 Feb 2023 08:12:25 -0800, Dixit, Ashutosh wrote:
>
> On Tue, 07 Feb 2023 01:32:44 -0800, Matthew Auld wrote:
> >
> > On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit
> > wrote:
> > >
> > > Previous documentation suggested that PL1 power limit is always
> > > enabled. However we now find this not to be the case on some
> > > platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> > > initialization.
> >
> > For some reason it looks like this change is impacting the atsm in CI:
> > https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
>
> Hmm, the change was meant for ATSM. Anyway let me try to get hold of an
> ATSM and see if I can figure out what might be going on with these
> seemingly unrelated failures and if I can repro them locally. Thanks!
Rodrigo/Matt,
I am proposing we revert this now and remerge again after investigating,
even getting ATSM systems to investigate is not easy so it might take a few
days to investigate. What do you guys think?
Thanks.
--
Ashutosh
>
> >
> > >
> > > Bspec: 51864
> > >
> > > v2: Add Bspec reference (Gwan-gyeong)
> > > v3: Add Fixes tag
> > >
> > > Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > Signed-off-by: Ashutosh Dixit
> > > Reviewed-by: Gwan-gyeong Mun
> > > ---
> > > drivers/gpu/drm/i915/i915_hwmon.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > index 1225bc432f0d5..4683a5b96eff1 100644
> > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private
> > > *i915)
> > > for_each_gt(gt, i915, i)
> > > hwm_energy(>ddat_gt[i], );
> > > }
> > > +
> > > + /* Enable PL1 power limit */
> > > + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > > + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> > > hwmon->rg.pkg_rapl_limit,
> > > + PKG_PWR_LIM_1_EN,
> > > PKG_PWR_LIM_1_EN);
> > > }
> > >
> > > void i915_hwmon_register(struct drm_i915_private *i915)
> > > --
> > > 2.38.0
> > >
[PATCH] fbdev: omapfb: cleanup inconsistent indentation
This cleans up the indentation according to the Linux kernel coding
style, and should fix the warning created by the kernel test robot.
Fixes: 8b08cf2b64f5a60594b07795b2ad518c6d044566 ("OMAP: add TI OMAP
framebuffer driver")
Reported-by: kernel test robot
Signed-off-by: Lucy Mielke
---
drivers/video/fbdev/omap/omapfb_main.c | 32 +++---
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/video/fbdev/omap/omapfb_main.c
b/drivers/video/fbdev/omap/omapfb_main.c
index 1f3df2055ff0..4b673daa32cb 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -78,7 +78,7 @@ static struct platform_device omapdss_device = {
.name = "omapdss_dss",
.id = -1,
.dev= {
- .release = omapdss_release,
+ .release= omapdss_release,
},
};
@@ -544,19 +544,25 @@ static int set_fb_var(struct fb_info *fbi,
var->yoffset = var->yres_virtual - var->yres;
if (plane->color_mode == OMAPFB_COLOR_RGB444) {
- var->red.offset = 8; var->red.length = 4;
- var->red.msb_right = 0;
- var->green.offset = 4; var->green.length = 4;
- var->green.msb_right = 0;
- var->blue.offset = 0; var->blue.length = 4;
- var->blue.msb_right = 0;
+ var->red.offset = 8;
+ var->red.length = 4;
+ var->red.msb_right = 0;
+ var->green.offset = 4;
+ var->green.length = 4;
+ var->green.msb_right= 0;
+ var->blue.offset= 0;
+ var->blue.length= 4;
+ var->blue.msb_right = 0;
} else {
- var->red.offset = 11; var->red.length = 5;
- var->red.msb_right = 0;
- var->green.offset = 5; var->green.length = 6;
- var->green.msb_right = 0;
- var->blue.offset = 0; var->blue.length = 5;
- var->blue.msb_right = 0;
+ var->red.offset = 11;
+ var->red.length = 5;
+ var->red.msb_right = 0;
+ var->green.offset = 5;
+ var->green.length = 6;
+ var->green.msb_right= 0;
+ var->blue.offset= 0;
+ var->blue.length= 5;
+ var->blue.msb_right = 0;
}
var->height = -1;
--
2.39.1
[PATCH] fbdev: omapfb: cleanup inconsistent indentation
This cleans up the indentation according to the Linux kernel coding
style, and should fix the warning created by the kernel test robot.
Fixes: 8b08cf2b64f5a60594b07795b2ad518c6d044566 ("OMAP: add TI OMAP
framebuffer driver")
Reported-by: kernel test robot
Signed-off-by: Lucy Mielke
---
drivers/video/fbdev/omap/omapfb_main.c | 32 +++---
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/video/fbdev/omap/omapfb_main.c
b/drivers/video/fbdev/omap/omapfb_main.c
index 1f3df2055ff0..4b673daa32cb 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -78,7 +78,7 @@ static struct platform_device omapdss_device = {
.name = "omapdss_dss",
.id = -1,
.dev= {
- .release = omapdss_release,
+ .release= omapdss_release,
},
};
@@ -544,19 +544,25 @@ static int set_fb_var(struct fb_info *fbi,
var->yoffset = var->yres_virtual - var->yres;
if (plane->color_mode == OMAPFB_COLOR_RGB444) {
- var->red.offset = 8; var->red.length = 4;
- var->red.msb_right = 0;
- var->green.offset = 4; var->green.length = 4;
- var->green.msb_right = 0;
- var->blue.offset = 0; var->blue.length = 4;
- var->blue.msb_right = 0;
+ var->red.offset = 8;
+ var->red.length = 4;
+ var->red.msb_right = 0;
+ var->green.offset = 4;
+ var->green.length = 4;
+ var->green.msb_right= 0;
+ var->blue.offset= 0;
+ var->blue.length= 4;
+ var->blue.msb_right = 0;
} else {
- var->red.offset = 11; var->red.length = 5;
- var->red.msb_right = 0;
- var->green.offset = 5; var->green.length = 6;
- var->green.msb_right = 0;
- var->blue.offset = 0; var->blue.length = 5;
- var->blue.msb_right = 0;
+ var->red.offset = 11;
+ var->red.length = 5;
+ var->red.msb_right = 0;
+ var->green.offset = 5;
+ var->green.length = 6;
+ var->green.msb_right= 0;
+ var->blue.offset= 0;
+ var->blue.length= 5;
+ var->blue.msb_right = 0;
}
var->height = -1;
--
2.39.1
Re: [PATCH v4 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
Hi Sascha,
On 2023-02-07 13:51, Sascha Hauer wrote:
> On Tue, Feb 07, 2023 at 11:01:26AM +, Jonas Karlman wrote:
>> Hi Sascha,
>>
>> On 2023-02-07 09:44, Sascha Hauer wrote:
>>> The Rockchip PLL drivers are currently table based and support only
>>> the most common pixelclocks. Discard all modes we cannot achieve
>>> at all. Normally the desired pixelclocks have an exact match in the
>>> PLL driver, nevertheless allow for a 0.1% error just in case.
>>>
>>> Tested-by: Nicolas Frattaroli
>>> Tested-by: Michael Riesch
>>> Tested-by: Dan Johansen
>>> Link:
>>> https://lore.kernel.org/r/20230118132213.2911418-4-s.ha...@pengutronix.de
>>> Signed-off-by: Sascha Hauer
>>> ---
>>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> index feba6b9becd6c..725952811752b 100644
>>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> @@ -256,10 +256,14 @@ dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi,
>>> void *data,
>>> {
>>> struct rockchip_hdmi *hdmi = data;
>>> const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
>>> - int pclk = mode->clock * 1000;
>>> + int rpclk, pclk = mode->clock * 1000;
>>> bool exact_match = hdmi->plat_data->phy_force_vendor;
>>> int i;
>>>
>>> + rpclk = clk_round_rate(hdmi->ref_clk, pclk);
>>> + if (abs(rpclk - pclk) > pclk / 1000)
>>> + return MODE_NOCLOCK;
>>
>> The ref_clk is optional and rk3228/rk3328 dts do not supply a ref or vpll
>> clock.
>
> That's a bit unfortunate as we can't do this check then on these SoCs.
>
> The clock is likely actually there in the system and maybe even in the
> clock driver, just not wired up to the HDMI. I don't know which one it
> is though, so I am afraid there's not much I can do about it other than
> just skipping the check when the clock is not there.
For rk3228/rk3328 I think just skipping the rate check when there is
no ref_clk should be fine.
The clock is provided by phy-rockchip-inno-hdmi.c for rk3228/rk3328. And
I recall we used to add ref/vpll clock to device tree to do something
similar in LibreELEC with our initial work-in-progress HDMI2.0 patches.
We have since then opted to just filter modes based on clk_round_rate
for !phy_force_vendor and instead extend the inno-hdmi pll table with
common hdmi/dvi clock rates, see [1] for the current state of RK HDMI2.0
related patches we use in LibreELEC.
Hopefully I can find some time in coming weeks to restart the work of
testing and sending those patches upstream, rebased on top of this series.
[1]
https://github.com/Kwiboo/linux-rockchip/compare/v6.2-rc7...rockchip-6.2-hdmi2.0
Regards,
Jonas
>
> Sascha
>
Re: [PATCH] drm/i915/hwmon: Enable PL1 power limit
On Tue, 07 Feb 2023 01:32:44 -0800, Matthew Auld wrote:
>
> On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit wrote:
> >
> > Previous documentation suggested that PL1 power limit is always
> > enabled. However we now find this not to be the case on some
> > platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> > initialization.
>
> For some reason it looks like this change is impacting the atsm in CI:
> https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
Hmm, the change was meant for ATSM. Anyway let me try to get hold of an
ATSM and see if I can figure out what might be going on with these
seemingly unrelated failures and if I can repro them locally. Thanks!
>
> >
> > Bspec: 51864
> >
> > v2: Add Bspec reference (Gwan-gyeong)
> > v3: Add Fixes tag
> >
> > Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > Signed-off-by: Ashutosh Dixit
> > Reviewed-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/i915_hwmon.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 1225bc432f0d5..4683a5b96eff1 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private
> > *i915)
> > for_each_gt(gt, i915, i)
> > hwm_energy(>ddat_gt[i], );
> > }
> > +
> > + /* Enable PL1 power limit */
> > + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> > hwmon->rg.pkg_rapl_limit,
> > + PKG_PWR_LIM_1_EN,
> > PKG_PWR_LIM_1_EN);
> > }
> >
> > void i915_hwmon_register(struct drm_i915_private *i915)
> > --
> > 2.38.0
> >
Re: DRM accel and debugfs/sysfs
On 2/7/23 12:43, Jeffrey Hugo wrote:
On 2/7/2023 4:31 AM, Maíra Canal wrote:
Hi Stanislaw,
On 2/1/23 12:20, Stanislaw Gruszka wrote:
Hi
I was about to send debugfs support for ivpu and noticed that there
are current changes that deprecate drm_devel->debugfs_init callback.
Further I looked at this commit [1], that stated we should not
use drm_minor for debugfs and sysfs. What is quite contrary to
what drm accel framework did in the first place.
So my question is how we should use debugfs/sysfs in accel?
Use it with old fashioned minor-centric way or change
the framework somehow ?
As we are trying to replace drm_debugfs_create_files() [1], it would
be nice to see the accel debugfs support use the new debugfs API. This
would mean using the debugfs_list from the drm_device, deprecating
the debugfs_init callback, and adding the a similar code snippet to
accel_debugfs_init:
list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry, _debugfs_entry_fops);
list_del(>list);
Maybe Daniel has some more thoughts on this matter, but I guess it
would be better to drop the use of the old-fashioned minor-centric
implementation in accel.
[1]
https://cgit.freedesktop.org/drm/drm-misc/tree/Documentation/gpu/todo.rst#n511
Best Regards,
- Maíra Canal
Thank you for the details Maira. It helps to explain what the todo is
suggesting. Is there an example of a driver/drm_device that uses debugfs_list
which you can easily point to?
The implementation of this device-centered infrastructure is linked in [1]
and an example of the conversion of debugfs APIs is linked in [2], and other
drivers such as v3d, vkms, vc4 and gud use this new API as well.
[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=1c9cacbea880513a896aee65a5c58007bcb55653
[2]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2e3ab8a6994f265bbd4dbd00448b84548f18464c
Best Regards,
- Maíra Canal
-Jeff
[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=99845faae7099cd704ebf67514c1157c26960a26
Regards
Stanislaw
Re: [PATCH 1/2] backlight: hx8357: switch to using gpiod API
On Mon, Feb 06, 2023 at 08:15:56PM -0800, Dmitry Torokhov wrote:
> On Mon, Feb 06, 2023 at 11:35:32AM +, Daniel Thompson wrote:
> > On Tue, Jan 31, 2023 at 02:57:06PM -0800, Dmitry Torokhov wrote:
> > > + dev_info(>dev, "im gpio[%d] is not here
> > > yet, deferring the probe\n",
> > > + i);
> > > + } else {
> > > + dev_err(>dev, "failed to request im
> > > gpio[%d]: %d\n",
> > > + i, ret);
> > > }
> >
> > These last two clauses should be updated to return dev_err_probe(...)
> > instead.
> >
> > With that change:
> > Reviewed-by: Daniel Thompson
>
> So you want to actually suppress the deferral message unless debug
> printks are enabled? So you want this to read:
>
>
> if (ret) {
> if (ret == -ENOENT) {
> if (i == 0)
> break;
>
> dev_err(>dev, "Missing im gpios[%d]\n", i);
> return -EINVAL;
> }
>
> return dev_err_probe(>dev, ret,
>"failed to request im gpio[%d]\n",
> i);
> }
>
> Did I get it right?
LGTM.
Daniel.
Re: drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5
Further information:
With the above fix, the very early boot console messages are not
rotated. adding "fbcon=rotate:1" to the kernel command line corrects
this. But these early boot console messages are still garbled - it
looks like the display driver in use at the time cannot write to the
screen fast enough - lines are half-formed before scrolling.
Note that this corrects itself and later boot messages are legible
before the plymouth splash (if in use). I can't see anything that
looks like useful information re the fb in journalctl immediately
preceding the first legible output seen during boot.
I've played around with console, earlycon and fbcon parms to no useful
effect. Any ideas?
Darrell
On Fri, 3 Feb 2023 at 18:32, Darrell Kavanagh
wrote:
>
> Hi,
>
> This is another Lenovo with detachable keyboard and 1200x1920 screen
> mounted sideways.
>
> The following has been tested with 6.2.0-rc6.
>
> Thanks,
> Darrell
>
> index 3659f04..590bb7b 100644
> --- a/kernel/drm_panel_orientation
> _quirks.c
> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> D330-10IGM"),
> },
> .driver_data = (void *)_rightside_up,
> + }, {/* Lenovo IdeaPad Duet 3 10IGL5 */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3
> 10IGL5"),
> + },
> + .driver_data = (void *)_rightside_up,
> }, {/* Lenovo Ideapad D330-10IGL (HD) */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
Re: DRM accel and debugfs/sysfs
On 2/7/2023 4:31 AM, Maíra Canal wrote:
Hi Stanislaw,
On 2/1/23 12:20, Stanislaw Gruszka wrote:
Hi
I was about to send debugfs support for ivpu and noticed that there
are current changes that deprecate drm_devel->debugfs_init callback.
Further I looked at this commit [1], that stated we should not
use drm_minor for debugfs and sysfs. What is quite contrary to
what drm accel framework did in the first place.
So my question is how we should use debugfs/sysfs in accel?
Use it with old fashioned minor-centric way or change
the framework somehow ?
As we are trying to replace drm_debugfs_create_files() [1], it would
be nice to see the accel debugfs support use the new debugfs API. This
would mean using the debugfs_list from the drm_device, deprecating
the debugfs_init callback, and adding the a similar code snippet to
accel_debugfs_init:
list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry, _debugfs_entry_fops);
list_del(>list);
Maybe Daniel has some more thoughts on this matter, but I guess it
would be better to drop the use of the old-fashioned minor-centric
implementation in accel.
[1]
https://cgit.freedesktop.org/drm/drm-misc/tree/Documentation/gpu/todo.rst#n511
Best Regards,
- Maíra Canal
Thank you for the details Maira. It helps to explain what the todo is
suggesting. Is there an example of a driver/drm_device that uses
debugfs_list which you can easily point to?
-Jeff
[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=99845faae7099cd704ebf67514c1157c26960a26
Regards
Stanislaw
Re: [PATCH] dt-bindings: display: panel: visionox,vtdr6130: add missing reg property
On 07/02/2023 11:04, Neil Armstrong wrote:
> Add missing reg property and update example to add dsi top node.
>
> Fixes: ef85db911134 ("dt-bindings: display: panel: document the Visionox
> VTDR6130 AMOLED DSI Panel")
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [PATCH v12 13/14] drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver
On 07/02/2023 16:26, Vinod Polimera wrote:
-Original Message-
From: Dmitry Baryshkov
Sent: Tuesday, January 31, 2023 6:29 PM
To: Vinod Polimera (QUIC) ; dri-
de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; robdcl...@gmail.com;
diand...@chromium.org; swb...@chromium.org; Kalyan Thota (QUIC)
; Kuogee Hsieh (QUIC)
; Vishnuvardhan Prodduturi (QUIC)
; Bjorn Andersson (QUIC)
; Abhinav Kumar (QUIC)
; Sankeerth Billakanti (QUIC)
Subject: Re: [PATCH v12 13/14] drm/msm/disp/dpu: add PSR support for eDP
interface in dpu driver
On 30/01/2023 17:11, Vinod Polimera wrote:
Enable PSR on eDP interface using drm self-refresh librabry.
This patch uses a trigger from self-refresh library to enter/exit
into PSR, when there are no updates from framework.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f29a339..60e5984 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
@@ -1021,6 +1022,9 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
DRM_DEBUG_KMS("crtc%d\n", crtc->base.id);
+ if (old_crtc_state->self_refresh_active)
+ return;
+
I have been looking at the crtc_needs_disable(). It explicitly mentions
that 'We also need to run through the crtc_funcs->disable() function
[..] if it's transitioning to self refresh mode...'. Don't we need to
perform some cleanup here (like disabling the vblank irq handling,
freeing the bandwidth, etc)?
When self refresh active is enabled, then we will clean up irq handling and
bandwidth etc.
The above case is to handle display off commit triggered when we are in psr as
all
the resources are already cleaned up . we just need to do an early return.
/* Disable/save vblank irq handling */
drm_crtc_vblank_off(crtc);
@@ -1577,7 +1581,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
*dev, struct drm_plane *plane,
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
- int i;
+ int i, ret;
dpu_crtc = kzalloc(sizeof(*dpu_crtc), GFP_KERNEL);
if (!dpu_crtc)
@@ -1614,6 +1618,13 @@ struct drm_crtc *dpu_crtc_init(struct
drm_device *dev, struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
+ ret = drm_self_refresh_helper_init(crtc);
+ if (ret) {
+ DPU_ERROR("Failed to initialize %s with self-refresh helpers
%d\n",
+ crtc->name, ret);
+ return ERR_PTR(ret);
+ }
+
DRM_DEBUG_KMS("%s: successfully initialized crtc\n", dpu_crtc-
name);
return crtc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 01b7509..450abb1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1212,11 +1213,24 @@ static void
dpu_encoder_virt_atomic_disable(struct drm_encoder *drm_enc,
struct drm_atomic_state *state)
{
struct dpu_encoder_virt *dpu_enc = NULL;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_state = NULL;
int i = 0;
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");
+ crtc = drm_atomic_get_old_crtc_for_encoder(state, drm_enc);
+ if (crtc)
+ old_state = drm_atomic_get_old_crtc_state(state, crtc);
+
+ /*
+ * The encoder is already disabled if self refresh mode was set earlier,
+ * in the old_state for the corresponding crtc.
+ */
+ if (old_state && old_state->self_refresh_active)
+ return;
+
Again the same question here, doesn't crtc_needs_disable() take care of
this clause? I might be missing something in the PSR state transitions.
Could you please add some explanation here?
Same usecase as above, applies to encoder disable also when triggered via
disable commit
When driver is in psr state.
Ack, thank you for the explanations. I'd like to take another glance
later today, but generally it look good to me.
--
With best wishes
Dmitry
Re: [PATCH v12 09/14] drm/msm/dp: disable self_refresh_aware after entering psr
On 07/02/2023 16:28, Vinod Polimera wrote: -Original Message- From: Dmitry Baryshkov Sent: Tuesday, January 31, 2023 6:19 PM To: Vinod Polimera (QUIC) ; dri- de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; freedr...@lists.freedesktop.org; devicet...@vger.kernel.org Cc: Sankeerth Billakanti (QUIC) ; linux- ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org; swb...@chromium.org; Kalyan Thota (QUIC) ; Kuogee Hsieh (QUIC) ; Vishnuvardhan Prodduturi (QUIC) ; Bjorn Andersson (QUIC) ; Abhinav Kumar (QUIC) Subject: Re: [PATCH v12 09/14] drm/msm/dp: disable self_refresh_aware after entering psr Can we please get rid of this somehow? On 30/01/2023 17:11, Vinod Polimera wrote: From: Sankeerth Billakanti Updated frames get queued if self_refresh_aware is set when the sink is in psr. To support bridge enable and avoid queuing of update frames, reset the self_refresh_aware state after entering psr. Signed-off-by: Sankeerth Billakanti Signed-off-by: Vinod Polimera --- drivers/gpu/drm/msm/dp/dp_drm.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) As I stated in v11's discussion, I do not like the way this change plays with the self_refresh_aware. Please find another way to work around the timing issue (let's probably continue the discussion back in v11). Currently we are not able to reproduce the issue with KASAN enabled and minimum cpu frequency builds. We can revisit this patch if it is reproduced in future. Meanwhile I think on handling it in a different way. Can we not consider this patch for current merge? Ack. -- With best wishes Dmitry
Re: [PATCH v2 4/4] drm/msm/dpu: reserve the resources on topology change
On 07/02/2023 16:29, Kalyan Thota wrote:
Some features like CTM can be enabled dynamically. Release
and reserve the DPU resources whenever a topology change
occurs such that required hw blocks are allocated appropriately.
Signed-off-by: Kalyan Thota
---
Changes in v1:
- Avoid mode_set call directly (Dmitry)
Changes in v2:
- Minor nits (Dmitry)
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 ++-
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 539b68b..85bd5645 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -204,6 +204,7 @@ struct dpu_crtc {
* @hw_ctls : List of active ctl paths
* @crc_source: CRC source
* @crc_frame_skip_count: Number of frames skipped before getting CRC
+ * @ctm_enabled : Cached color management enablement state
*/
struct dpu_crtc_state {
struct drm_crtc_state base;
@@ -225,6 +226,7 @@ struct dpu_crtc_state {
enum dpu_crtc_crc_source crc_source;
int crc_frame_skip_count;
+ bool ctm_enabled;
};
#define to_dpu_crtc_state(x) \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3920efd..7bb4840 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -217,6 +217,22 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+static bool _dpu_enc_is_dspp_changed(struct drm_crtc_state *crtc_state,
+ struct msm_display_topology topology)
+{
+ struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
+
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ return true;
I think this check doesn't belong to the is_dspp_changed() function.
+
+ if ((cstate->ctm_enabled && !topology.num_dspp) ||
+ (!cstate->ctm_enabled && topology.num_dspp)) {
+ crtc_state->mode_changed = true;
+ return true;
+ }
+
+ return false;
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
@@ -642,14 +658,15 @@ static int dpu_encoder_virt_atomic_check(
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode, crtc_state);
+ _dpu_enc_is_dspp_changed(crtc_state, topology);
+
/*
* Release and Allocate resources on every modeset
-* Dont allocate when active is false.
*/
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
dpu_rm_release(global_state, drm_enc);
- if (!crtc_state->active_changed || crtc_state->active)
+ if (crtc_state->enable)
ret = dpu_rm_reserve(_kms->rm, global_state,
drm_enc, crtc_state, topology);
}
@@ -1022,7 +1039,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
- int num_lm, num_ctl, num_pp, num_dsc;
+ int num_lm, num_ctl, num_pp, num_dsc, num_dspp;
unsigned int dsc_mask = 0;
int i;
@@ -1053,7 +1070,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
- dpu_rm_get_assigned_resources(_kms->rm, global_state,
+ num_dspp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_DSPP, hw_dspp,
ARRAY_SIZE(hw_dspp));
@@ -1084,7 +1101,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
}
cstate->num_mixers = num_lm;
-
+ cstate->ctm_enabled = !!num_dspp;
dpu_enc->connector = conn_state->connector;
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
--
With best wishes
Dmitry
Re: [PATCH v2 3/4] drm/msm/dpu: avoid unnecessary check in DPU reservations
On 07/02/2023 16:29, Kalyan Thota wrote: Return immediately on failure, this will make dpu reservations part look cleaner. Signed-off-by: Kalyan Thota --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 2/4] drm/msm/dpu: add DSPPs into reservation upon a CTM request
On 07/02/2023 16:29, Kalyan Thota wrote: Add DSPP blocks into the topology for reservation, if there is a CTM request for that composition. Signed-off-by: Kalyan Thota --- Changes in v1: - Minor nits (Dmitry) Changes in v2: - Populate DSPPs into the reservation only if CTM is requested (Dmitry) --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add GPIO display mux binding
Hello Pin-yen, On Tue, Feb 07, 2023 at 06:30:36PM +0800, Pin-yen Lin wrote: > On Tue, Feb 7, 2023 at 6:25 PM Laurent Pinchart wrote: > > On Tue, Feb 07, 2023 at 06:07:44PM +0800, Pin-yen Lin wrote: > > > On Wed, Jan 18, 2023 at 4:17 AM Rob Herring wrote: > > > > On Mon, Jan 16, 2023 at 07:08:19PM +0800, Pin-yen Lin wrote: > > > > > From: Nicolas Boichat > > > > > > > > > > Add bindings for Generic GPIO mux driver. > > > > > > > > > > Signed-off-by: Nicolas Boichat > > > > > Signed-off-by: Pin-yen Lin > > > > > --- > > > > > > > > > > Changes in v2: > > > > > - Referenced existing dt-binding schemas from graph.yaml > > > > > - Added ddc-i2c-bus into the bindings > > > > > > > > > > .../bindings/display/bridge/gpio-mux.yaml | 95 > > > > > +++ > > > > > 1 file changed, 95 insertions(+) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > new file mode 100644 > > > > > index ..da29ba078f05 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > @@ -0,0 +1,95 @@ > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: Generic display mux (1 input, 2 outputs) > > > > > + > > > > > +maintainers: > > > > > + - Nicolas Boichat > > > > > + > > > > > +description: | > > > > > + This bindings describes a simple display (e.g. HDMI) mux, that has > > > > > 1 > > > > > + input, and 2 outputs. The mux status is controlled by hardware, and > > > > > + its status is read back using a GPIO. > > > > > + > > > > > +properties: > > > > > + compatible: > > > > > +const: gpio-display-mux > > > > > + > > > > > + detect-gpios: > > > > > +maxItems: 1 > > > > > +description: GPIO that indicates the active output > > > > > > > > What are we detecting? That implies an input, but this is selecting the > > > > output path, right? Or what does 'mux status is controlled by hardware' > > > > mean exactly? Something else? That does not sound very generic. > > > > > > The GPIO (or any kind of MUX) is an input that indicates where the > > > output should go. The actual "output selection" procedure is done in > > > the driver. That is, the driver monitors this GPIO and selects the > > > output path accordingly. In our use case, the GPIO is reported by the > > > embedded controller on the device. > > > > > > [1] listed other similar bridges that can leverage this driver, so we > > > called this driver "generic". > > > > > > [1]: > > > https://lore.kernel.org/all/CAJMQK-jGw8kJFNjoHjeZUL+3NCiOS2hgGERnAnMwNsL_cm_J=q...@mail.gmail.com/ > > > > > > > In any case, we have a common mux binding so any kind of mux control > > > > could be used here, not just GPIO. Then you can make this just a generic > > > > display mux. > > > > > > Thanks for sharing this, I'll update the binding in the next version. > > > > > > > > + > > > > > + ddc-i2c-bus: > > > > > +description: phandle link to the I2C controller used for DDC > > > > > EDID probing > > > > > +$ref: /schemas/types.yaml#/definitions/phandle > > > > > > > > This belongs in the connector node(s). > > > > > > The HDMI bridge before the MUX doesn't (and doesn't have to) know that > > > its next bridge is a MUX. We put it here so that the HDMI bridge can > > > parse the phandle and get the bus node. > > > > How does that work, does the HDMI encoder driver parse the ddc-i2c-bus > > property of the next DT node in the OF graph ? > > Yes. In our use case, mtk_hdmi.c[2] checks the remote node of its > output port to get the bus phandle. sun4i_hdmi_enc.c[3] seems to use a > similar approach as well. Peeking into nodes of other devices is a bad practice. I don't know how the code you mention below got merged, but I'm pretty sure I would have flagged it if I had reviewed the patches :-) The ddc-i2c-bus property should instead be specified in the node where it logically belongs (in this case, the connector node), and handled by the connector driver. You can then use drm_bridge operations to tie things together, like done in the drm_bridge_connector helper. I'd recommend using the drm_bridge_connector helper if you can, either as-is, or by extending it. > [2]: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/mediatek/mtk_hdmi.c#L1500 > [3]: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c#L240 > > > > > > + > > > > > + ports: > > > > > +$ref: /schemas/graph.yaml#/properties/ports > > > > > + > > > > > +properties: > > > > > + port@0: > > > > > +$ref:
Re: [PATCH v2 1/4] drm/msm/dpu: clear DSPP reservations in rm release
On 07/02/2023 16:29, Kalyan Thota wrote:
Clear DSPP reservations from the global state during
rm release
Fixes: e47616df008b ("drm/msm/dpu: add support for color
processing blocks in dpu driver")
This should fit into a single line (even it is longer than the
recommended length).
And no empty lines between Fixes and next tags.
Signed-off-by: Kalyan Thota
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 73b3442..718ea0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -572,6 +572,8 @@ void dpu_rm_release(struct dpu_global_state *global_state,
ARRAY_SIZE(global_state->ctl_to_enc_id), enc->base.id);
_dpu_rm_clear_mapping(global_state->dsc_to_enc_id,
ARRAY_SIZE(global_state->dsc_to_enc_id), enc->base.id);
+ _dpu_rm_clear_mapping(global_state->dspp_to_enc_id,
+ ARRAY_SIZE(global_state->dspp_to_enc_id), enc->base.id);
}
int dpu_rm_reserve(
--
With best wishes
Dmitry
Re: [RFC PATCH] drm: Create documentation about device resets
On 2/7/23 14:30, Pekka Paalanen wrote: > On Mon, 23 Jan 2023 21:38:11 +0100 > Christian König wrote: >> Am 23.01.23 um 21:26 schrieb André Almeida: >>> >>> diff --git a/Documentation/gpu/drm-reset.rst >>> b/Documentation/gpu/drm-reset.rst >>> new file mode 100644 >>> index ..0dd11a469cf9 >>> --- /dev/null >>> +++ b/Documentation/gpu/drm-reset.rst >>> @@ -0,0 +1,51 @@ >>> + >>> +DRM Device Reset >>> + >>> + >>> +The GPU stack is really complex and is prone to errors, from hardware bugs, >>> +faulty applications and everything in the many layers in between. To >>> recover >>> +from this kind of state, sometimes is needed to reset the GPU. Unproper >>> handling >>> +of GPU resets can lead to an unstable userspace. This page describes >>> what's the >>> +expected behaviour from DRM drivers to do in those situations, from >>> usermode >>> +drivers and compositors as well. >>> + >>> +Robustness >>> +-- >>> + >>> +First of all, application robust APIs, when available, should be used. This >>> +allows the application to correctly recover and continue to run after a >>> reset. >>> +Apps that doesn't use this should be promptly killed when the kernel driver >>> +detects that it's in broken state. Specifically guidelines for some APIs: >>> + >> >>> +- OpenGL: During a reset, KMD kill processes that haven't ARB Robustness >>> + enabled, assuming they can't recover. >> >> This is a pretty clear NAK from my side to this approach. The KMD should >> never mess with an userspace process directly in such a way. >> >> Instead use something like this "OpenGL: KMD signals the abortion of >> submitted commands and the UMD should then react accordingly and abort >> the application.". > > what Christian said, plus I would not assume that robust programs will > always respond by creating a new context. They could also switch > to a software renderer, [...] That is indeed what Firefox does. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
Geert,
On 07/02/2023 14:30, neil.armstr...@linaro.org wrote:
On 07/02/2023 11:19, Geert Uytterhoeven wrote:
Hi Neil,
On Tue, Feb 7, 2023 at 11:02 AM Geert Uytterhoeven wrote:
On Tue, Feb 7, 2023 at 10:59 AM Neil Armstrong
wrote:
On 07/02/2023 10:40, Geert Uytterhoeven wrote:
On Tue, Jan 10, 2023 at 5:37 PM Dmitry Baryshkov
wrote:
On 10/01/2023 08:57, Laurentiu Palcu wrote:
On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
On 09/01/2023 18:21, Laurentiu Palcu wrote:
It looks like there are some issues with this patchset... :/ I just
fetched the drm-tip and, with these patches included, the "Hot plug
detection already enabled" warning is back for i.MX DCSS.
Could you please provide a backtrace?
Sure, see below:
I wondered, why didn't I see this on msm, my main target nowadays. The
msm driver is calling msm_kms_helper_poll_init() after initializing
fbdev, so all previous kms_helper_poll_enable() calls return early.
I think I have the fix ready. Let me test it locally before posting.
Is this fix available?
Do you have a lore link?
The fix at [1] has been applied on 2023-01-26
[1]
https://lore.kernel.org/all/20230124104548.3234554-1-dmitry.barysh...@linaro.org/
Applied where? linux-next does not have it.
commit cbf143b282c64e59
("drm/probe_helper: extract two helper functions") in next-20230127
next-20230130 next-20230131
commit d33a54e3991dfce8
("drm/probe_helper: sort out poll_running vs poll_enabled") in
next-20230127 next-20230130 next-20230131
but not in any later version?
$ git log --oneline --author=dmitry next-20230207
drivers/gpu/drm/drm_probe_helper.c
c8268795c9a9 drm/probe-helper: enable and disable HPD on connectors
78b991ccfa64 drm/poll-helper: merge drm_kms_helper_poll_disable() and _fini()
$ cat Next/SHA1s | grep drm
drm-fixes 4ec5183ec48656cec489c49f989c508b68b518e3
drm-intel-fixes 4c7b9344cadbed477372c75e3c0a8cfd542f5990
drm-misc-fixes 8f20660f053cefd4693e69cfff9cf58f4f7c4929
drm 1c0db6d84f8e0ac8f14178f13250e36ebcf457ee
drm-misc d20a8f409259f1782f080b434054854020878f23
drm-intel 155c6b16eec2eaaaf6c71abf2d5e71641770d7ba
drm-tegra b9930311641cf2ed905a84aabe27e8f3868aee4a
drm-msm dbd7a2a941b8cbf9e5f79a777ed9fe0090eebb61
drm-msm-lumag 1d233b1cb149ec78c20fac58331b27bb460f9558
imx-drm 927d8fd465adbaaad6cce82f840d489d7c378f29
so weren't merged into drm-misc, I'll ping Thomas & Maxime on irc.
Thomas just told me the commits were cherry-picked into drm-misc-next-fixes
and should appear on tomorrow's linux-next tree.
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-next-fixes=91f43949662c9eb4a443203a188e806df8290bc9
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-next-fixes=a4e771729a51168bc36317effaa9962e336d4f5e
Neil
Neil
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 3/4] drm/msm/dpu: avoid unnecessary check in DPU reservations
Return immediately on failure, this will make dpu reservations
part look cleaner.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 46d2a5c..3920efd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -636,25 +636,22 @@ static int dpu_encoder_virt_atomic_check(
if (ret) {
DPU_ERROR_ENC(dpu_enc,
"mode unsupported, phys idx %d\n", i);
- break;
+ return ret;
}
}
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
- /* Reserve dynamic resources now. */
- if (!ret) {
- /*
-* Release and Allocate resources on every modeset
-* Dont allocate when active is false.
-*/
- if (drm_atomic_crtc_needs_modeset(crtc_state)) {
- dpu_rm_release(global_state, drm_enc);
+ /*
+* Release and Allocate resources on every modeset
+* Dont allocate when active is false.
+*/
+ if (drm_atomic_crtc_needs_modeset(crtc_state)) {
+ dpu_rm_release(global_state, drm_enc);
- if (!crtc_state->active_changed || crtc_state->active)
- ret = dpu_rm_reserve(_kms->rm, global_state,
- drm_enc, crtc_state, topology);
- }
+ if (!crtc_state->active_changed || crtc_state->active)
+ ret = dpu_rm_reserve(_kms->rm, global_state,
+ drm_enc, crtc_state, topology);
}
trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags);
--
2.7.4
[PATCH v2 4/4] drm/msm/dpu: reserve the resources on topology change
Some features like CTM can be enabled dynamically. Release
and reserve the DPU resources whenever a topology change
occurs such that required hw blocks are allocated appropriately.
Signed-off-by: Kalyan Thota
---
Changes in v1:
- Avoid mode_set call directly (Dmitry)
Changes in v2:
- Minor nits (Dmitry)
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 ++-
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 539b68b..85bd5645 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -204,6 +204,7 @@ struct dpu_crtc {
* @hw_ctls : List of active ctl paths
* @crc_source: CRC source
* @crc_frame_skip_count: Number of frames skipped before getting CRC
+ * @ctm_enabled : Cached color management enablement state
*/
struct dpu_crtc_state {
struct drm_crtc_state base;
@@ -225,6 +226,7 @@ struct dpu_crtc_state {
enum dpu_crtc_crc_source crc_source;
int crc_frame_skip_count;
+ bool ctm_enabled;
};
#define to_dpu_crtc_state(x) \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3920efd..7bb4840 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -217,6 +217,22 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+static bool _dpu_enc_is_dspp_changed(struct drm_crtc_state *crtc_state,
+ struct msm_display_topology topology)
+{
+ struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
+
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ return true;
+
+ if ((cstate->ctm_enabled && !topology.num_dspp) ||
+ (!cstate->ctm_enabled && topology.num_dspp)) {
+ crtc_state->mode_changed = true;
+ return true;
+ }
+
+ return false;
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
@@ -642,14 +658,15 @@ static int dpu_encoder_virt_atomic_check(
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
+ _dpu_enc_is_dspp_changed(crtc_state, topology);
+
/*
* Release and Allocate resources on every modeset
-* Dont allocate when active is false.
*/
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
dpu_rm_release(global_state, drm_enc);
- if (!crtc_state->active_changed || crtc_state->active)
+ if (crtc_state->enable)
ret = dpu_rm_reserve(_kms->rm, global_state,
drm_enc, crtc_state, topology);
}
@@ -1022,7 +1039,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
- int num_lm, num_ctl, num_pp, num_dsc;
+ int num_lm, num_ctl, num_pp, num_dsc, num_dspp;
unsigned int dsc_mask = 0;
int i;
@@ -1053,7 +1070,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
- dpu_rm_get_assigned_resources(_kms->rm, global_state,
+ num_dspp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_DSPP, hw_dspp,
ARRAY_SIZE(hw_dspp));
@@ -1084,7 +1101,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
}
cstate->num_mixers = num_lm;
-
+ cstate->ctm_enabled = !!num_dspp;
dpu_enc->connector = conn_state->connector;
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
--
2.7.4
[PATCH v2 1/4] drm/msm/dpu: clear DSPP reservations in rm release
Clear DSPP reservations from the global state during
rm release
Fixes: e47616df008b ("drm/msm/dpu: add support for color
processing blocks in dpu driver")
Signed-off-by: Kalyan Thota
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 73b3442..718ea0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -572,6 +572,8 @@ void dpu_rm_release(struct dpu_global_state *global_state,
ARRAY_SIZE(global_state->ctl_to_enc_id), enc->base.id);
_dpu_rm_clear_mapping(global_state->dsc_to_enc_id,
ARRAY_SIZE(global_state->dsc_to_enc_id), enc->base.id);
+ _dpu_rm_clear_mapping(global_state->dspp_to_enc_id,
+ ARRAY_SIZE(global_state->dspp_to_enc_id), enc->base.id);
}
int dpu_rm_reserve(
--
2.7.4
[PATCH v2 0/4] Reserve DSPPs based on user request
This series will enable color features on sc7280 target which has primary panel as eDP The series removes DSPP allocation based on encoder type and allows the DSPP reservation based on user request via CTM. The series will release/reserve the dpu resources when ever there is a topology change to suit the new requirements. Kalyan Thota (4): drm/msm/dpu: clear DSPP reservations in rm release drm/msm/dpu: add DSPPs into reservation upon a CTM request drm/msm/dpu: avoid unnecessary check in DPU reservations drm/msm/dpu: reserve the resources on topology change drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 61 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 + 3 files changed, 40 insertions(+), 25 deletions(-) -- 2.7.4
[PATCH v2 2/4] drm/msm/dpu: add DSPPs into reservation upon a CTM request
Add DSPP blocks into the topology for reservation, if there
is a CTM request for that composition.
Signed-off-by: Kalyan Thota
---
Changes in v1:
- Minor nits (Dmitry)
Changes in v2:
- Populate DSPPs into the reservation only if CTM is requested (Dmitry)
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b..46d2a5c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ struct drm_crtc_state *crtc_state)
{
struct msm_display_topology topology = {0};
int i, intf_count = 0;
@@ -563,8 +564,7 @@ static struct msm_display_topology dpu_encoder_get_topology(
* 1 LM, 1 INTF
* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
*
-* Adding color blocks only to primary interface if available in
-* sufficient number
+* Add dspps to the reservation requirements if ctm is requested
*/
if (intf_count == 2)
topology.num_lm = 2;
@@ -573,11 +573,8 @@ static struct msm_display_topology
dpu_encoder_get_topology(
else
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
- if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
- if (dpu_kms->catalog->dspp &&
- (dpu_kms->catalog->dspp_count >= topology.num_lm))
- topology.num_dspp = topology.num_lm;
- }
+ if (crtc_state->ctm)
+ topology.num_dspp = topology.num_lm;
topology.num_enc = 0;
topology.num_intf = intf_count;
@@ -643,7 +640,7 @@ static int dpu_encoder_virt_atomic_check(
}
}
- topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
+ topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
/* Reserve dynamic resources now. */
if (!ret) {
--
2.7.4
RE: [PATCH v12 09/14] drm/msm/dp: disable self_refresh_aware after entering psr
> -Original Message- > From: Dmitry Baryshkov > Sent: Tuesday, January 31, 2023 6:19 PM > To: Vinod Polimera (QUIC) ; dri- > de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > freedr...@lists.freedesktop.org; devicet...@vger.kernel.org > Cc: Sankeerth Billakanti (QUIC) ; linux- > ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org; > swb...@chromium.org; Kalyan Thota (QUIC) ; > Kuogee Hsieh (QUIC) ; Vishnuvardhan > Prodduturi (QUIC) ; Bjorn Andersson (QUIC) > ; Abhinav Kumar (QUIC) > > Subject: Re: [PATCH v12 09/14] drm/msm/dp: disable self_refresh_aware > after entering psr > > On 30/01/2023 17:11, Vinod Polimera wrote: > > From: Sankeerth Billakanti > > > > Updated frames get queued if self_refresh_aware is set when the > > sink is in psr. To support bridge enable and avoid queuing of update > > frames, reset the self_refresh_aware state after entering psr. > > > > Signed-off-by: Sankeerth Billakanti > > Signed-off-by: Vinod Polimera > > --- > > drivers/gpu/drm/msm/dp/dp_drm.c | 25 - > > 1 file changed, 24 insertions(+), 1 deletion(-) > > As I stated in v11's discussion, I do not like the way this change plays > with the self_refresh_aware. Please find another way to work around the > timing issue (let's probably continue the discussion back in v11). > Currently we are not able to reproduce the issue with KASAN enabled and minimum cpu frequency builds. We can revisit this patch if it is reproduced in future. Meanwhile I think on handling it in a different way. Can we not consider this patch for current merge? > -- > With best wishes > Dmitry Thanks, Vinod P.
RE: [PATCH v12 13/14] drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Tuesday, January 31, 2023 6:29 PM
> To: Vinod Polimera (QUIC) ; dri-
> de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; robdcl...@gmail.com;
> diand...@chromium.org; swb...@chromium.org; Kalyan Thota (QUIC)
> ; Kuogee Hsieh (QUIC)
> ; Vishnuvardhan Prodduturi (QUIC)
> ; Bjorn Andersson (QUIC)
> ; Abhinav Kumar (QUIC)
> ; Sankeerth Billakanti (QUIC)
>
> Subject: Re: [PATCH v12 13/14] drm/msm/disp/dpu: add PSR support for eDP
> interface in dpu driver
>
>
> On 30/01/2023 17:11, Vinod Polimera wrote:
> > Enable PSR on eDP interface using drm self-refresh librabry.
> > This patch uses a trigger from self-refresh library to enter/exit
> > into PSR, when there are no updates from framework.
> >
> > Signed-off-by: Kalyan Thota
> > Signed-off-by: Vinod Polimera
> > Reviewed-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 13 -
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
> > 3 files changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > index f29a339..60e5984 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "dpu_kms.h"
> > #include "dpu_hw_lm.h"
> > @@ -1021,6 +1022,9 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
> >
> > DRM_DEBUG_KMS("crtc%d\n", crtc->base.id);
> >
> > + if (old_crtc_state->self_refresh_active)
> > + return;
> > +
>
> I have been looking at the crtc_needs_disable(). It explicitly mentions
> that 'We also need to run through the crtc_funcs->disable() function
> [..] if it's transitioning to self refresh mode...'. Don't we need to
> perform some cleanup here (like disabling the vblank irq handling,
> freeing the bandwidth, etc)?
When self refresh active is enabled, then we will clean up irq handling and
bandwidth etc.
The above case is to handle display off commit triggered when we are in psr as
all
the resources are already cleaned up . we just need to do an early return.
>
> > /* Disable/save vblank irq handling */
> > drm_crtc_vblank_off(crtc);
> >
> > @@ -1577,7 +1581,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
> *dev, struct drm_plane *plane,
> > {
> > struct drm_crtc *crtc = NULL;
> > struct dpu_crtc *dpu_crtc = NULL;
> > - int i;
> > + int i, ret;
> >
> > dpu_crtc = kzalloc(sizeof(*dpu_crtc), GFP_KERNEL);
> > if (!dpu_crtc)
> > @@ -1614,6 +1618,13 @@ struct drm_crtc *dpu_crtc_init(struct
> drm_device *dev, struct drm_plane *plane,
> > /* initialize event handling */
> > spin_lock_init(_crtc->event_lock);
> >
> > + ret = drm_self_refresh_helper_init(crtc);
> > + if (ret) {
> > + DPU_ERROR("Failed to initialize %s with self-refresh helpers
> > %d\n",
> > + crtc->name, ret);
> > + return ERR_PTR(ret);
> > + }
> > +
> > DRM_DEBUG_KMS("%s: successfully initialized crtc\n", dpu_crtc-
> >name);
> > return crtc;
> > }
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 01b7509..450abb1 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -1212,11 +1213,24 @@ static void
> dpu_encoder_virt_atomic_disable(struct drm_encoder *drm_enc,
> > struct drm_atomic_state *state)
> > {
> > struct dpu_encoder_virt *dpu_enc = NULL;
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *old_state = NULL;
> > int i = 0;
> >
> > dpu_enc = to_dpu_encoder_virt(drm_enc);
> > DPU_DEBUG_ENC(dpu_enc, "\n");
> >
> > + crtc = drm_atomic_get_old_crtc_for_encoder(state, drm_enc);
> > + if (crtc)
> > + old_state = drm_atomic_get_old_crtc_state(state, crtc);
> > +
> > + /*
> > + * The encoder is already disabled if self refresh mode was set
> > earlier,
> > + * in the old_state for the corresponding crtc.
> > + */
> > + if (old_state && old_state->self_refresh_active)
> > + return;
> > +
>
> Again the same question here, doesn't crtc_needs_disable() take care of
> this clause? I might be missing something in the PSR state transitions.
> Could you please add some explanation here?
Same usecase as above, applies to encoder disable also when triggered via
disable commit
When driver is in psr state.
>
> >
Re: [RFC PATCH] drm: Create documentation about device resets
On Mon, 23 Jan 2023 21:38:11 +0100 Christian König wrote: > Am 23.01.23 um 21:26 schrieb André Almeida: > > Create a document that specifies how to deal with DRM device resets for > > kernel and userspace drivers. > > > > Signed-off-by: André Almeida > > --- > > Documentation/gpu/drm-reset.rst | 51 + > > Documentation/gpu/index.rst | 1 + > > 2 files changed, 52 insertions(+) > > create mode 100644 Documentation/gpu/drm-reset.rst > > > > diff --git a/Documentation/gpu/drm-reset.rst > > b/Documentation/gpu/drm-reset.rst > > new file mode 100644 > > index ..0dd11a469cf9 > > --- /dev/null > > +++ b/Documentation/gpu/drm-reset.rst > > @@ -0,0 +1,51 @@ > > + > > +DRM Device Reset > > + > > + > > +The GPU stack is really complex and is prone to errors, from hardware bugs, > > +faulty applications and everything in the many layers in between. To > > recover > > +from this kind of state, sometimes is needed to reset the GPU. Unproper > > handling > > +of GPU resets can lead to an unstable userspace. This page describes > > what's the > > +expected behaviour from DRM drivers to do in those situations, from > > usermode > > +drivers and compositors as well. > > + > > +Robustness > > +-- > > + > > +First of all, application robust APIs, when available, should be used. This > > +allows the application to correctly recover and continue to run after a > > reset. > > +Apps that doesn't use this should be promptly killed when the kernel driver > > +detects that it's in broken state. Specifically guidelines for some APIs: > > + > > > +- OpenGL: During a reset, KMD kill processes that haven't ARB Robustness > > + enabled, assuming they can't recover. > > This is a pretty clear NAK from my side to this approach. The KMD should > never mess with an userspace process directly in such a way. > > Instead use something like this "OpenGL: KMD signals the abortion of > submitted commands and the UMD should then react accordingly and abort > the application.". > > > +- Vulkan: Assumes that every app is able to deal with > > ``VK_ERROR_DEVICE_LOST``, > > + so KMD doesn't kill any. If it doesn't do it right, it's considered a > > broken > > + application and UMD will deal with it. > > Again, pleas remove the "KMD kill" reference. > > > + > > +Kernel mode driver > > +-- > > + > > +The KMD should be able to detect that something is wrong with the > > application > > Please replace *should* with *must* here, this is mandatory or otherwise > core memory management can run into deadlocks during reclaim. > > Regards, > Christian. > > > +and that a reset is needed to take place to recover the device (e.g. an > > endless > > +wait). It needs to properly track the context that is broken and mark it as > > +dead, so any other syscalls to that context should be further rejected. The > > +other contexts should be preserved when possible, avoid crashing the rest > > of > > +userspace. KMD can ban a file descriptor that keeps causing resets, as it's > > +likely in a broken loop. > > + > > +User mode driver > > + > > + > > +During a reset, UMD should be aware that rejected syscalls indicates that > > the > > +context is broken and for robust apps the recovery should happen for the > > +context. Non-robust apps would be already terminated by KMD. If no new > > context > > +is created for some time, it is assumed that the recovery didn't work, so > > UMD > > +should terminate it. Hi, what Christian said, plus I would not assume that robust programs will always respond by creating a new context. They could also switch to a software renderer, or simply not do graphics again until something else happens. > > + > > +Compositors > > +--- > > + > > +(In the long term) compositors should be robust as well to properly deal > > with it > > +errors. Init systems should be aware of the compositor status and reset it > > if is > > +broken. I don't know how init systems could do that, or what difference does it make to an init system whether the display server is robust or not. Display servers can get stuck for other reasons as well. They may also be live-stuck, where they respond to keepalive, serve clients, and deliver input events, but still do not update the screen. You can't tell if that's a malfunction or expected. Have you checked https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#device-hot-unplug that you are consistent with hot-unplug plans? Thanks, pq > > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst > > index b99dede9a5b1..300b2529bd39 100644 > > --- a/Documentation/gpu/index.rst > > +++ b/Documentation/gpu/index.rst > > @@ -9,6 +9,7 @@ Linux GPU Driver Developer's Guide > > drm-mm > > drm-kms > > drm-kms-helpers > > + drm-reset > > drm-uapi > > drm-usage-stats > > driver-uapi > pgpgP3d2zFocM.pgp
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
On 07/02/2023 11:19, Geert Uytterhoeven wrote:
Hi Neil,
On Tue, Feb 7, 2023 at 11:02 AM Geert Uytterhoeven wrote:
On Tue, Feb 7, 2023 at 10:59 AM Neil Armstrong
wrote:
On 07/02/2023 10:40, Geert Uytterhoeven wrote:
On Tue, Jan 10, 2023 at 5:37 PM Dmitry Baryshkov
wrote:
On 10/01/2023 08:57, Laurentiu Palcu wrote:
On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
On 09/01/2023 18:21, Laurentiu Palcu wrote:
It looks like there are some issues with this patchset... :/ I just
fetched the drm-tip and, with these patches included, the "Hot plug
detection already enabled" warning is back for i.MX DCSS.
Could you please provide a backtrace?
Sure, see below:
I wondered, why didn't I see this on msm, my main target nowadays. The
msm driver is calling msm_kms_helper_poll_init() after initializing
fbdev, so all previous kms_helper_poll_enable() calls return early.
I think I have the fix ready. Let me test it locally before posting.
Is this fix available?
Do you have a lore link?
The fix at [1] has been applied on 2023-01-26
[1]
https://lore.kernel.org/all/20230124104548.3234554-1-dmitry.barysh...@linaro.org/
Applied where? linux-next does not have it.
commit cbf143b282c64e59
("drm/probe_helper: extract two helper functions") in next-20230127
next-20230130 next-20230131
commit d33a54e3991dfce8
("drm/probe_helper: sort out poll_running vs poll_enabled") in
next-20230127 next-20230130 next-20230131
but not in any later version?
$ git log --oneline --author=dmitry next-20230207
drivers/gpu/drm/drm_probe_helper.c
c8268795c9a9 drm/probe-helper: enable and disable HPD on connectors
78b991ccfa64 drm/poll-helper: merge drm_kms_helper_poll_disable() and _fini()
$ cat Next/SHA1s | grep drm
drm-fixes 4ec5183ec48656cec489c49f989c508b68b518e3
drm-intel-fixes 4c7b9344cadbed477372c75e3c0a8cfd542f5990
drm-misc-fixes 8f20660f053cefd4693e69cfff9cf58f4f7c4929
drm 1c0db6d84f8e0ac8f14178f13250e36ebcf457ee
drm-miscd20a8f409259f1782f080b434054854020878f23
drm-intel 155c6b16eec2eaaaf6c71abf2d5e71641770d7ba
drm-tegra b9930311641cf2ed905a84aabe27e8f3868aee4a
drm-msm dbd7a2a941b8cbf9e5f79a777ed9fe0090eebb61
drm-msm-lumag 1d233b1cb149ec78c20fac58331b27bb460f9558
imx-drm 927d8fd465adbaaad6cce82f840d489d7c378f29
so weren't merged into drm-misc, I'll ping Thomas & Maxime on irc.
Neil
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] [CI 1/4] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs
Hi all,
On Mon, Feb 06, 2023 at 01:48:53PM +0200, Imre Deak wrote:
> Add the MST topology for a CRTC to the atomic state if the driver
> needs to force a modeset on the CRTC after the encoder compute config
> functions are called.
>
> Later the MST encoder's disable hook also adds the state, but that isn't
> guaranteed to work (since in that hook getting the state may fail, which
> can't be handled there). This should fix that, while a later patch fixes
> the use of the MST state in the disable hook.
>
> v2: Add missing forward struct declartions, caught by hdrtest.
> v3: Factor out intel_dp_mst_add_topology_state_for_connector() used
> later in the patchset.
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: sta...@vger.kernel.org # 6.1
> Reviewed-by: Ville Syrjälä # v2
> Reviewed-by: Lyude Paul
> Signed-off-by: Imre Deak
Is it ok to merge these 4 patches (also at [1]), via the i915 tree?
If so could it be also acked from the AMD and Nouveau side?
[1] https://patchwork.freedesktop.org/series/113703/
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 61
> drivers/gpu/drm/i915/display/intel_dp_mst.h | 4 ++
> 3 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 12ade593c..38106cf63b3b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5936,6 +5936,10 @@ int intel_modeset_all_pipes(struct intel_atomic_state
> *state,
> if (ret)
> return ret;
>
> + ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc);
> + if (ret)
> + return ret;
> +
> ret = intel_atomic_add_affected_planes(state, crtc);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 8b0e4defa3f10..f3cb12dcfe0a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1223,3 +1223,64 @@ bool intel_dp_mst_is_slave_trans(const struct
> intel_crtc_state *crtc_state)
> return crtc_state->mst_master_transcoder != INVALID_TRANSCODER &&
> crtc_state->mst_master_transcoder != crtc_state->cpu_transcoder;
> }
> +
> +/**
> + * intel_dp_mst_add_topology_state_for_connector - add MST topology state
> for a connector
> + * @state: atomic state
> + * @connector: connector to add the state for
> + * @crtc: the CRTC @connector is attached to
> + *
> + * Add the MST topology state for @connector to @state.
> + *
> + * Returns 0 on success, negative error code on failure.
> + */
> +static int
> +intel_dp_mst_add_topology_state_for_connector(struct intel_atomic_state
> *state,
> + struct intel_connector *connector,
> + struct intel_crtc *crtc)
> +{
> + struct drm_dp_mst_topology_state *mst_state;
> +
> + if (!connector->mst_port)
> + return 0;
> +
> + mst_state = drm_atomic_get_mst_topology_state(>base,
> +
> >mst_port->mst_mgr);
> + if (IS_ERR(mst_state))
> + return PTR_ERR(mst_state);
> +
> + mst_state->pending_crtc_mask |= drm_crtc_mask(>base);
> +
> + return 0;
> +}
> +
> +/**
> + * intel_dp_mst_add_topology_state_for_crtc - add MST topology state for a
> CRTC
> + * @state: atomic state
> + * @crtc: CRTC to add the state for
> + *
> + * Add the MST topology state for @crtc to @state.
> + *
> + * Returns 0 on success, negative error code on failure.
> + */
> +int intel_dp_mst_add_topology_state_for_crtc(struct intel_atomic_state
> *state,
> + struct intel_crtc *crtc)
> +{
> + struct drm_connector *_connector;
> + struct drm_connector_state *conn_state;
> + int i;
> +
> + for_each_new_connector_in_state(>base, _connector, conn_state,
> i) {
> + struct intel_connector *connector =
> to_intel_connector(_connector);
> + int ret;
> +
> + if (conn_state->crtc != >base)
> + continue;
> +
> + ret = intel_dp_mst_add_topology_state_for_connector(state,
> connector, crtc);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.h
> b/drivers/gpu/drm/i915/display/intel_dp_mst.h
> index f7301de6cdfb3..f1815bb722672 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.h
> @@ -8,6 +8,8 @@
>
> #include
>
> +struct intel_atomic_state;
> +struct intel_crtc;
> struct intel_crtc_state;
> struct intel_digital_port;
> struct intel_dp;
> @@ -18,5 +20,7
Re: [PATCH v4 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
On Tue, Feb 07, 2023 at 11:01:26AM +, Jonas Karlman wrote:
> Hi Sascha,
>
> On 2023-02-07 09:44, Sascha Hauer wrote:
> > The Rockchip PLL drivers are currently table based and support only
> > the most common pixelclocks. Discard all modes we cannot achieve
> > at all. Normally the desired pixelclocks have an exact match in the
> > PLL driver, nevertheless allow for a 0.1% error just in case.
> >
> > Tested-by: Nicolas Frattaroli
> > Tested-by: Michael Riesch
> > Tested-by: Dan Johansen
> > Link:
> > https://lore.kernel.org/r/20230118132213.2911418-4-s.ha...@pengutronix.de
> > Signed-off-by: Sascha Hauer
> > ---
> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > index feba6b9becd6c..725952811752b 100644
> > --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > @@ -256,10 +256,14 @@ dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi,
> > void *data,
> > {
> > struct rockchip_hdmi *hdmi = data;
> > const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
> > - int pclk = mode->clock * 1000;
> > + int rpclk, pclk = mode->clock * 1000;
> > bool exact_match = hdmi->plat_data->phy_force_vendor;
> > int i;
> >
> > + rpclk = clk_round_rate(hdmi->ref_clk, pclk);
> > + if (abs(rpclk - pclk) > pclk / 1000)
> > + return MODE_NOCLOCK;
>
> The ref_clk is optional and rk3228/rk3328 dts do not supply a ref or vpll
> clock.
That's a bit unfortunate as we can't do this check then on these SoCs.
The clock is likely actually there in the system and maybe even in the
clock driver, just not wired up to the HDMI. I don't know which one it
is though, so I am afraid there's not much I can do about it other than
just skipping the check when the clock is not there.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 00/21] Enable Colorspace connector property in amdgpu
On Fri, 13 Jan 2023 11:24:07 -0500 Harry Wentland wrote: > This patchset enables the DP and HDMI infoframe properties > in amdgpu. > > The first two patches are not completely related to the rest. The > first patch allows for HDR_OUTPUT_METADATA with EOTFs that are > unknown in the kernel. > > The second one prints a connector's max_bpc as part of the atomic > state debugfs print. > > The following patches rework the connector colorspace code to > 1) allow for easy printing of the colorspace in the drm_atomic >state debugfs, and > 2) allow drivers to specify the supported colorspaces on a >connector. > > The rest of the patches deal with the Colorspace enablement > in amdgpu. > > Why do drivers need to specify supported colorspaces? The amdgpu > driver needs support for RGB-to-YCbCr conversion when we drive > the display in YCbCr. This is currently not implemented for all > colorspaces. > > Since the Colorspace property didn't have an IGT test I added > one to kms_hdr. The relevant patchset can be found on the IGT > mailing list or on > https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/hdr-colorimetry > > We tested v1 of the patchset and confirmed that the infoframes > are as expected for both DP and HDMI when running the IGT > colorimetry tests. > > Open Items > -- > > A couple comments from Pekka about colorspace documentation are > left unaddressed. I hope they won't block merging this set but > should still be addressed separately. > > Pekka's questions really got me thinking of how this colorspace > property should be used and working with it more closely with > Joshua who is enabling HDR in gamescope made me wonder even more. > > Uma, is there a (canonical, upstream) userspace that uses this > property that I can look at to understand more? > > One of the key challenges that is currently not addressed is that > userspace is expected to pick a colorspace format straight from the > list of definitions out of the DP or HDMI spec. But the kernel > driver are the ones deciding on the output encoding (RGB, YCBCR444, > YCBCR420, etc.). So there is no way for userspace to decide correctly > between, for example, BT2020_RGB, BT2020_CYCC, BT2020_YCC. > > So we end up in a scenario where gamescope sets BT2020_RGB but we > output YCBCR444 so have to correct the colorspace value to > BT2020_YCC. This in turn breaks the colorspace IGT tests I > wrote. I don't think "fixing" the IGT tests to accept this is > the right thing to do. > > The way it stands this patchset allows us to specify the output > colorspace on amdgpu and we try to do the right thing, but I don't > thing the way the colorspace property is defined is right. We're trying > to expose things to userspace that should be under driver control. A > much better approach would be to give userspace options for colorspace > that are not tied to DP or HDMI specs, i.e., sRGB, BT709, BT2020, etc., > and have the driver do the right thing to fill the infoframe, e.g., by > picking BT2020_YCC if the requested colorspace is BT2020 and the > is YCBCR444. Hi Harry, well explained. Indeed, if you want to keep the driver in control of the encoding on the monitor cable, then your suggestion seems correct (ignoring the question whether it breaks something existing). I do recall something about letting userspace control the encoding on the cable though, particularly when it affects performance or quality. E.g. 4:2:0 sub-sampling might be wanted in some cases and unwanted in others. It's a bit similar to bpc. The trade-off may be frame rate or resolution. It might better to know that the hardware cannot do what you ask, than to silently degrade. E.g. if you use sub-pixel rendering, you really do not want 4:2:0. That's compatible with your suggestion on changing the Colorspace property, I think it would complement it. Cable encoding parameters could be other properties, which might also be on "auto". If Colorspace property cannot be changed, then options I haven't seen discussed yet are have it force the cable encoding parameters, or another new property replacing it. > If no upstream userspace currently makes use of this property I > can make that change, i.e., no longer tie the colorspace property > directly to the infoframe and reduce the options to sRGB, BT709, > BT601, and BT2020 (and possibly opRGB). > > v2: > - Tested with DP and HDMI analyzers > - Confirmed driver will fallback to lower bpc when needed > - Dropped hunk to set HDMI AVI infoframe as it was a no-op > - Fixed BT.2020 YCbCr colorimetry (JoshuaAshton) > - Simplify initialization of supported colorspaces (Jani) > - Fix kerneldoc (kernel test robot) I recall saying this before, but in the series there are occurrences where sRGB is spelled as "RGB". I find that very confusing that "RGB" would imply anything about colorimetry when it's just a color model. Sometimes it might not be sRGB because the "default RGB" has probably not been sRGB for many years
Re: [PATCH v2 18/21] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB
On Wed, 25 Jan 2023 12:59:53 + Joshua Ashton wrote: > On 1/23/23 20:30, Sebastian Wick wrote: > > A new property to control YCC and subsampling would be the more > > complete path here. If we actually want to fix this in the short-term > > though, we should handle the YCC and RGB Colorspace values as > > equivalent, everywhere. Technically we're breaking the user space API > > here so it should be documented on the KMS property and other drivers > > must be adjusted accordingly as well. > > I am happy with treating 2020_YCC and 2020_RGB as the same. > > I think having the YCC/RGB split here in Colorspace is a mistake. > Pixel encoding should be completely separate from colorspace from a uAPI > perspective when we want to expose that. > It's just a design flaw from when it was added as it just mirrors the > values in the colorimetry packets 1:1. I understand why this happened, > and I don't think it's a big deal for us to correct ourselves now: > > I suggest we deprecate the _YCC variants, treat them the same as the RGB > enum to avoid any potential uAPI breakage and key the split entirely off > the pixel_encoding value. > > That way when we do want to plumb more explicit pixel encoding down the > line, userspace only has to manage one thing. There's no advantage for > anything more here. Sounds good to me! Thanks, pq > > - Joshie ✨ > > > > > On Fri, Jan 13, 2023 at 5:26 PM Harry Wentland > > wrote: > >> > >> From: Joshua Ashton > >> > >> Userspace might not aware whether we're sending RGB or YCbCr > >> data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is > >> requested but the output encoding is YCbCr we should > >> send COLOR_SPACE_2020_YCBCR. > >> > >> Signed-off-by: Joshua Ashton > >> Signed-off-by: Harry Wentland > >> Cc: Pekka Paalanen > >> Cc: Sebastian Wick > >> Cc: vitaly.pros...@amd.com > >> Cc: Joshua Ashton > >> Cc: dri-devel@lists.freedesktop.org > >> Cc: amd-...@lists.freedesktop.org > >> Reviewed-by: Harry Wentland > >> --- > >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 - > >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> > >> 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 f74b125af31f..16940ea61b59 100644 > >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >> @@ -5184,7 +5184,10 @@ get_output_color_space(const struct dc_crtc_timing > >> *dc_crtc_timing, > >> color_space = COLOR_SPACE_ADOBERGB; > >> break; > >> case DRM_MODE_COLORIMETRY_BT2020_RGB: > >> - color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > >> + if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) > >> + color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > >> + else > >> + color_space = COLOR_SPACE_2020_YCBCR; > >> break; > >> case DRM_MODE_COLORIMETRY_BT2020_YCC: > >> color_space = COLOR_SPACE_2020_YCBCR; > >> -- > >> 2.39.0 > >> > > pgpNaVoGHcHtR.pgp Description: OpenPGP digital signature
Re: [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
On Tue, Feb 07, 2023 at 10:46:49AM +, Jonas Karlman wrote:
> Hi Sascha,
> On 2023-02-07 09:44, Sascha Hauer wrote:
> > The different VOP variants support different maximum resolutions. Reject
> > resolutions that are not supported by a specific variant.
> >
> > This hasn't been a problem in the upstream driver so far as 1920x1080
> > has been the maximum resolution supported by the HDMI driver and that
> > resolution is supported by all VOP variants. Now with higher resolutions
> > supported in the HDMI driver we have to limit the resolutions to the
> > ones supported by the VOP.
> >
> > The actual maximum resolutions are taken from the Rockchip downstream
> > Kernel.
> >
> > Signed-off-by: Sascha Hauer
> > ---
> >
> > Notes:
> > Changes since v3:
> > - new patch
> >
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ++
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
> > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index fa1f4ee6d1950..96b6bd8d17803 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -1174,6 +1174,20 @@ static void vop_crtc_disable_vblank(struct drm_crtc
> > *crtc)
> > spin_unlock_irqrestore(>irq_lock, flags);
> > }
> >
> > +static enum drm_mode_status vop_crtc_mode_valid(struct drm_crtc *crtc,
> > + const struct drm_display_mode
> > *mode)
> > +{
> > + struct vop *vop = to_vop(crtc);
> > +
> > + if (vop->data->max_xres && mode->hdisplay > vop->data->max_xres)
> > + return MODE_BAD_HVALUE;
> > +
> > + if (vop->data->max_yres && mode->vdisplay > vop->data->max_yres)
> > + return MODE_BAD_VVALUE;
> > +
> > + return MODE_OK;
> > +}
> > +
> > static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> > const struct drm_display_mode *mode,
> > struct drm_display_mode *adjusted_mode)
> > @@ -1585,6 +1599,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc
> > *crtc,
> > }
> >
> > static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
> > + .mode_valid = vop_crtc_mode_valid,
> > .mode_fixup = vop_crtc_mode_fixup,
> > .atomic_check = vop_crtc_atomic_check,
> > .atomic_begin = vop_crtc_atomic_begin,
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > index 8502849833d93..5c4875ca3f270 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > @@ -225,6 +225,8 @@ struct vop_data {
> > const struct vop_win_data *win;
> > unsigned int win_size;
> > unsigned int lut_size;
> > + unsigned int max_xres;
> > + unsigned int max_yres;
>
> I would suggest using the same struct vop_rect max_input/output as the
> vop2 driver instead of handling this differently between the two.
As it was me who introduced struct vop_rect in the vop2 driver I
probably have to agree ;)
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Mon, Feb 06, 2023 at 07:42:32PM -0500, Lyude Paul wrote:
> On Wed, 2023-02-01 at 17:04 +0200, Imre Deak wrote:
> >
> > Yes, this patch should have no functional change, so please check what
> > would apply to other drivers as well.
> >
> > Could you also check Ville's comment about storing start_slot elsewhere
> > than the atomic state (leaving only time_slots there). I wonder if that
> > would work, at least it would simplify things I think.
>
> Ideally it'd be nice if we could have all this info in the atomic commit, but
> yeah - you're not the first person to find this a bit confusing. FWIW though,
> the way we store start_slot right now is intended to follow the same kind of
> behavior we have with atomic CRTC commit dependencies, I think I also made it
> that way so all of the state would be in a single place but there's no hard
> requirement for it.
As I understood the atomic state should be precomputed during atomic
check and not changed later during the commit phase. In case of
start_slot this would mean knowing in advance the actual (driver
specific) disabling / enabling sequence of the payloads, not sure how
feasible it is to figure that out. start_slot also changes dynamically
as each payload is disabled, so these intermediate versions of the field
would need to be tracked somehow separately from the final (precomputed)
versions.
> So if you guys think it'd be better design-wise to store this something else,
> I've got no strong feelings either way
> >
> > > For 0-2:
> > >
> > > Reviewed-by: Lyude Paul
> >
> > Thanks.
> >
> > >
> > > >
> > > > Cc: Lyude Paul
> > > > Cc: Ville Syrjälä
> > > > Cc: Ben Skeggs
> > > > Cc: Karol Herbst
> > > > Cc: Harry Wentland
> > > > Cc: Alex Deucher
> > > > Cc: Wayne Lin
> > > > Cc: sta...@vger.kernel.org # 6.1
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Reviewed-by: Ville Syrjälä
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
> > > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> > > > include/drm/display/drm_dp_mst_helper.h | 3 ++-
> > > > 5 files changed, 21 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > index a50319fc42b11..180d3893b68da 100644
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > @@ -208,7 +208,7 @@ bool
> > > > dm_helpers_dp_mst_write_payload_allocation_table(
> > > > if (enable)
> > > > drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
> > > > else
> > > > - drm_dp_remove_payload(mst_mgr, mst_state, payload);
> > > > + drm_dp_remove_payload(mst_mgr, mst_state, payload,
> > > > payload);
> > > >
> > > > /* mst_mgr->->payloads are VC payload notify MST branch using
> > > > DPCD or
> > > > * AUX message. The sequence is slot 1-63 allocated sequence
> > > > for each
> > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > index 847c10aa2098c..1990ff5dc7ddd 100644
> > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > @@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > > > * drm_dp_remove_payload() - Remove an MST payload
> > > > * @mgr: Manager to use.
> > > > * @mst_state: The MST atomic state
> > > > - * @payload: The payload to write
> > > > + * @old_payload: The payload with its old state
> > > > + * @new_payload: The payload to write
> > > > *
> > > > * Removes a payload from an MST topology if it was successfully
> > > > assigned a start slot. Also updates
> > > > * the starting time slots of all other payloads which would have been
> > > > shifted towards the start of
> > > > @@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > > > */
> > > > void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
> > > >struct drm_dp_mst_topology_state *mst_state,
> > > > - struct drm_dp_mst_atomic_payload *payload)
> > > > + const struct drm_dp_mst_atomic_payload
> > > > *old_payload,
> > > > + struct drm_dp_mst_atomic_payload
> > > > *new_payload)
> > > > {
> > > > struct drm_dp_mst_atomic_payload *pos;
> > > > bool send_remove = false;
> > > >
> > > > /* We failed to make the payload, so nothing to do */
> > > > - if (payload->vc_start_slot == -1)
> > > > + if (new_payload->vc_start_slot == -1)
> > > > return;
>
Re: [PATCH] drm/ast: Fix start address computation
On 07/02/2023 12:17, Thomas Zimmermann wrote:
Hi
Am 07.02.23 um 11:53 schrieb Jocelyn Falempe:
During the driver conversion to shmem, there is a missing page shift when
computing the start address in GPU memory.
This leads to graphic garbage when connecting to the remote BMC,
depending
on the PCI start address.
Tested on a sr645 affected by this bug.
Fixes: f2fa5a99ca81 ("drm/ast: Convert ast to SHMEM")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c
b/drivers/gpu/drm/ast/ast_mode.c
index c7443317c747..d75e4a7611b3 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -714,7 +714,7 @@ static int ast_primary_plane_init(struct
ast_private *ast)
struct ast_plane *ast_primary_plane = >primary_plane;
struct drm_plane *primary_plane = _primary_plane->base;
void __iomem *vaddr = ast->vram;
- u64 offset = ast->vram_base;
+ u64 offset = ast->vram_base << PAGE_SHIFT;
That can't be the problem, I think. vram_base is already an address. [1]
In the old code, drm_gem_vram_pg_offset() returned a page index. So
shifting it to the left here is most likely incorrect.
Can you verify that the new offset is the same as the old one?
Yes, I was also a bit unsure about this fix.
In my case, with the old code:
PCI base address is 0xce00
with old code:
start address (which is 24bits) was 0
with shmem code:
start address is 0x80
So the additional page shift makes it 0, which fixes the display.
I was wondering if this start address is not an offset in the GPU
memory, and in this case the primary plane offset should always be 0 ?
Best regards,
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.2-rc7/source/drivers/gpu/drm/ast/ast_mm.c#L96
unsigned long cursor_size = roundup(AST_HWC_SIZE +
AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
unsigned long size = ast->vram_fb_available - cursor_size;
int ret;
Re: DRM accel and debugfs/sysfs
Hi Stanislaw,
On 2/1/23 12:20, Stanislaw Gruszka wrote:
Hi
I was about to send debugfs support for ivpu and noticed that there
are current changes that deprecate drm_devel->debugfs_init callback.
Further I looked at this commit [1], that stated we should not
use drm_minor for debugfs and sysfs. What is quite contrary to
what drm accel framework did in the first place.
So my question is how we should use debugfs/sysfs in accel?
Use it with old fashioned minor-centric way or change
the framework somehow ?
As we are trying to replace drm_debugfs_create_files() [1], it would
be nice to see the accel debugfs support use the new debugfs API. This
would mean using the debugfs_list from the drm_device, deprecating
the debugfs_init callback, and adding the a similar code snippet to
accel_debugfs_init:
list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry,
_debugfs_entry_fops);
list_del(>list);
Maybe Daniel has some more thoughts on this matter, but I guess it
would be better to drop the use of the old-fashioned minor-centric
implementation in accel.
[1]
https://cgit.freedesktop.org/drm/drm-misc/tree/Documentation/gpu/todo.rst#n511
Best Regards,
- Maíra Canal
[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=99845faae7099cd704ebf67514c1157c26960a26
Regards
Stanislaw
Re: [PATCH] drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()
Hi
Am 05.02.23 um 13:51 schrieb Asahi Lina:
Other functions touching shmem->sgt take the pages lock, so do that here
Really? I was just locking at the Lima driver and it apparently access
sgt without locking in [1]. Not that I disagree with the patch in general.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/lima/lima_gem.c#L21
too. drm_gem_shmem_get_pages() & co take the same lock, so move to the
_locked() variants to avoid recursive locking.
Discovered while auditing locking to write the Rust abstractions.
Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
Fixes: 4fa3d66f132b ("drm/shmem: Do dma_unmap_sg before purging pages")
Signed-off-by: Asahi Lina
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 54 --
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index b602cd72a120..2c559b310cad 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -681,23 +681,7 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
drm_gem_shmem_object *shmem)
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
-/**
- * drm_gem_shmem_get_pages_sgt - Pin pages, dma map them, and return a
- * scatter/gather table for a shmem GEM object.
- * @shmem: shmem GEM object
- *
- * This function returns a scatter/gather table suitable for driver usage. If
- * the sg table doesn't exist, the pages are pinned, dma-mapped, and a sg
- * table created.
- *
- * This is the main function for drivers to get at backing storage, and it
hides
- * and difference between dma-buf imported and natively allocated objects.
- * drm_gem_shmem_get_sg_table() should not be directly called by drivers.
- *
- * Returns:
- * A pointer to the scatter/gather table of pinned pages or errno on failure.
- */
-struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_shmem_object
*shmem)
+static struct sg_table *drm_gem_shmem_get_pages_sgt_locked(struct
drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = >base;
int ret;
@@ -708,7 +692,7 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct
drm_gem_shmem_object *shmem)
WARN_ON(obj->import_attach);
- ret = drm_gem_shmem_get_pages(shmem);
+ ret = drm_gem_shmem_get_pages_locked(shmem);
if (ret)
return ERR_PTR(ret);
@@ -730,10 +714,40 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_shmem_object *shmem)
sg_free_table(sgt);
kfree(sgt);
err_put_pages:
- drm_gem_shmem_put_pages(shmem);
+ drm_gem_shmem_put_pages_locked(shmem);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(drm_gem_shmem_get_pages_sgt);
+
+/**
+ * drm_gem_shmem_get_pages_sgt - Pin pages, dma map them, and return a
+ * scatter/gather table for a shmem GEM object.
+ * @shmem: shmem GEM object
+ *
+ * This function returns a scatter/gather table suitable for driver usage. If
+ * the sg table doesn't exist, the pages are pinned, dma-mapped, and a sg
+ * table created.
+ *
+ * This is the main function for drivers to get at backing storage, and it
hides
+ * and difference between dma-buf imported and natively allocated objects.
+ * drm_gem_shmem_get_sg_table() should not be directly called by drivers.
+ *
+ * Returns:
+ * A pointer to the scatter/gather table of pinned pages or errno on failure.
+ */
+struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_shmem_object
*shmem)
+{
+ int ret;
+ struct sg_table *sgt;
+
+ ret = mutex_lock_interruptible(>pages_lock);
+ if (ret)
+ return ERR_PTR(ret);
+ sgt = drm_gem_shmem_get_pages_sgt_locked(shmem);
+ mutex_unlock(>pages_lock);
+
+ return sgt;
+}
+EXPORT_SYMBOL(drm_gem_shmem_get_pages_sgt);
/**
* drm_gem_shmem_prime_import_sg_table - Produce a shmem GEM object from
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] drm/ast: Fix start address computation
Hi
Am 07.02.23 um 11:53 schrieb Jocelyn Falempe:
During the driver conversion to shmem, there is a missing page shift when
computing the start address in GPU memory.
This leads to graphic garbage when connecting to the remote BMC, depending
on the PCI start address.
Tested on a sr645 affected by this bug.
Fixes: f2fa5a99ca81 ("drm/ast: Convert ast to SHMEM")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c7443317c747..d75e4a7611b3 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -714,7 +714,7 @@ static int ast_primary_plane_init(struct ast_private *ast)
struct ast_plane *ast_primary_plane = >primary_plane;
struct drm_plane *primary_plane = _primary_plane->base;
void __iomem *vaddr = ast->vram;
- u64 offset = ast->vram_base;
+ u64 offset = ast->vram_base << PAGE_SHIFT;
That can't be the problem, I think. vram_base is already an address.
[1] In the old code, drm_gem_vram_pg_offset() returned a page index. So
shifting it to the left here is most likely incorrect.
Can you verify that the new offset is the same as the old one?
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.2-rc7/source/drivers/gpu/drm/ast/ast_mm.c#L96
unsigned long cursor_size = roundup(AST_HWC_SIZE +
AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
unsigned long size = ast->vram_fb_available - cursor_size;
int ret;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v4 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
Hi Sascha,
On 2023-02-07 09:44, Sascha Hauer wrote:
> The Rockchip PLL drivers are currently table based and support only
> the most common pixelclocks. Discard all modes we cannot achieve
> at all. Normally the desired pixelclocks have an exact match in the
> PLL driver, nevertheless allow for a 0.1% error just in case.
>
> Tested-by: Nicolas Frattaroli
> Tested-by: Michael Riesch
> Tested-by: Dan Johansen
> Link:
> https://lore.kernel.org/r/20230118132213.2911418-4-s.ha...@pengutronix.de
> Signed-off-by: Sascha Hauer
> ---
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index feba6b9becd6c..725952811752b 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -256,10 +256,14 @@ dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi,
> void *data,
> {
> struct rockchip_hdmi *hdmi = data;
> const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
> - int pclk = mode->clock * 1000;
> + int rpclk, pclk = mode->clock * 1000;
> bool exact_match = hdmi->plat_data->phy_force_vendor;
> int i;
>
> + rpclk = clk_round_rate(hdmi->ref_clk, pclk);
> + if (abs(rpclk - pclk) > pclk / 1000)
> + return MODE_NOCLOCK;
The ref_clk is optional and rk3228/rk3328 dts do not supply a ref or vpll clock.
Regards,
Jonas
> +
> for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
> /*
>* For vendor specific phys force an exact match of the
> pixelclock
[PATCH] drm/ast: Fix start address computation
During the driver conversion to shmem, there is a missing page shift when
computing the start address in GPU memory.
This leads to graphic garbage when connecting to the remote BMC, depending
on the PCI start address.
Tested on a sr645 affected by this bug.
Fixes: f2fa5a99ca81 ("drm/ast: Convert ast to SHMEM")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c7443317c747..d75e4a7611b3 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -714,7 +714,7 @@ static int ast_primary_plane_init(struct ast_private *ast)
struct ast_plane *ast_primary_plane = >primary_plane;
struct drm_plane *primary_plane = _primary_plane->base;
void __iomem *vaddr = ast->vram;
- u64 offset = ast->vram_base;
+ u64 offset = ast->vram_base << PAGE_SHIFT;
unsigned long cursor_size = roundup(AST_HWC_SIZE +
AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
unsigned long size = ast->vram_fb_available - cursor_size;
int ret;
--
2.39.1
Re: [Nouveau] [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces
On 2/7/23 10:35, Christian König wrote: Am 06.02.23 um 19:20 schrieb Danilo Krummrich: On 2/6/23 17:14, Christian König wrote: Concentrating this discussion on a very big misunderstanding first. Am 06.02.23 um 14:27 schrieb Danilo Krummrich: [SNIP] My understanding is that userspace is fully responsible on the parts of the GPU VA space it owns. This means that userspace needs to take care to *not* ask the kernel to modify mappings that are in use currently. This is a completely wrong assumption! Take a look at what games like Forza Horizzon are doing. Basically that game allocates a very big sparse area and fills it with pages from BOs while shaders are accessing it. And yes, as far as I know this is completely valid behavior. I also think this is valid behavior. That's not the problem I'm trying to describe. In this case userspace modifies the VA space *intentionally* while shaders are accessing it, because it knows that the shaders can deal with reading 0s. No, it's perfectly valid for userspace to modify the VA space even if shaders are not supposed to deal with reading 0s. Just to have it all in place, the example I gave was: - two virtually contiguous buffers A and B - binding 1 mapped to A with BO offset 0 - binding 2 mapped to B with BO offset length(A) What I did not mention both A and B aren't sparse buffers in this example, although it probably doesn't matter too much. Since the conditions to do so are given, we merge binding 1 and binding 2 right at the time when binding 2 is requested. To do so a driver might unmap binding 1 for a very short period of time (e.g. to (re-)map the freshly merged binding with a different page size if possible). Nope, that's not correct handling. I agree, and that's exactly what I'm trying to say. However, I start noticing that this is not correct if it happens within the same buffer as well. From userspace perspective buffer A is ready to use before applying binding 2 to buffer B, hence it would be illegal to touch binding 1 again when userspace asks the kernel to map binding 2 to buffer B. Besides that I think there is no point in merging between buffers anyway because we'd end up splitting such a merged mapping anyway later on when one of the two buffers is destroyed. Also, I think the same applies to sparse buffers as well, a mapping within A isn't expected to be re-mapped just because something is mapped to B. However, in this context I start wondering if re-mapping in the context of merge and split is allowed at all, even within the same sparse buffer (and even with a separate page table for sparse mappings as described in my last mail; shaders would never fault). See, your assumption is that userspace/applications don't modify the VA space intentionally while the GPU is accessing it is just bluntly speaking incorrect. I don't assume that. The opposite is the case. My assumption is that it's always OK for userspace to intentionally modify the VA space. However, I also assumed that if userspace asks for e.g. a new mapping within a certain buffer it is OK for the kernel to apply further changes (e.g. re-organize PTs to split or merge) to the VA space of which userspace isn't aware of. At least as long as they happen within the bounds of this particular buffer, but not for other buffers. I think the reasoning I had in mind was that I thought if userspace asks for any modification of a given portion of the VA space (that is a VKBuffer) userspace must assume that until this modification (e.g. re-organization of PTs) is complete reading 0s intermediately may happen. This seems to be clearly wrong. When you have a VA address which is mapped to buffer A and accessed by some GPU shaders it is perfectly valid for the application to say "map it again to the same buffer A". It is also perfectly valid for an application to re-map this region to a different buffer B, it's just not defined when the access then transits from A to B. (AFAIK this is currently worked on in a new specification). So when your page table updates result in the shader to intermediately get 0s in return, because you change the underlying mapping you simply have some implementation bug in Nouveau. Luckily that's not the case (anymore). I don't know how Nvidia hw handles this, and yes it's quite complicated on AMD hw as well because our TLBs are not really made for this use case, but I'm 100% sure that this is possible since it is still part of some of the specifications (mostly Vulkan I think). To sum it up as far as I can see by giving the regions to the kernel is not something you would want for Nouveau either. If, as it turns out, it's also not allowed to do what I described above within the same VKBuffer, I agree the bounds aren't needed for merging. However, I still don't see why we would want to merge over buffer boundaries, because ultimately we'll end up splitting such a merged
Re: [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
Hi Sascha,
On 2023-02-07 09:44, Sascha Hauer wrote:
> The different VOP variants support different maximum resolutions. Reject
> resolutions that are not supported by a specific variant.
>
> This hasn't been a problem in the upstream driver so far as 1920x1080
> has been the maximum resolution supported by the HDMI driver and that
> resolution is supported by all VOP variants. Now with higher resolutions
> supported in the HDMI driver we have to limit the resolutions to the
> ones supported by the VOP.
>
> The actual maximum resolutions are taken from the Rockchip downstream
> Kernel.
>
> Signed-off-by: Sascha Hauer
> ---
>
> Notes:
> Changes since v3:
> - new patch
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +
> 3 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fa1f4ee6d1950..96b6bd8d17803 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1174,6 +1174,20 @@ static void vop_crtc_disable_vblank(struct drm_crtc
> *crtc)
> spin_unlock_irqrestore(>irq_lock, flags);
> }
>
> +static enum drm_mode_status vop_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode
> *mode)
> +{
> + struct vop *vop = to_vop(crtc);
> +
> + if (vop->data->max_xres && mode->hdisplay > vop->data->max_xres)
> + return MODE_BAD_HVALUE;
> +
> + if (vop->data->max_yres && mode->vdisplay > vop->data->max_yres)
> + return MODE_BAD_VVALUE;
> +
> + return MODE_OK;
> +}
> +
> static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> @@ -1585,6 +1599,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
> }
>
> static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
> + .mode_valid = vop_crtc_mode_valid,
> .mode_fixup = vop_crtc_mode_fixup,
> .atomic_check = vop_crtc_atomic_check,
> .atomic_begin = vop_crtc_atomic_begin,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 8502849833d93..5c4875ca3f270 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -225,6 +225,8 @@ struct vop_data {
> const struct vop_win_data *win;
> unsigned int win_size;
> unsigned int lut_size;
> + unsigned int max_xres;
> + unsigned int max_yres;
I would suggest using the same struct vop_rect max_input/output as the
vop2 driver instead of handling this differently between the two.
Regards,
Jonas
>
> #define VOP_FEATURE_OUTPUT_RGB10 BIT(0)
> #define VOP_FEATURE_INTERNAL_RGB BIT(1)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 014f99e8928e3..dc1a703d9d1a8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -181,6 +181,8 @@ static const struct vop_data rk3036_vop = {
> .output = _output,
> .win = rk3036_vop_win_data,
> .win_size = ARRAY_SIZE(rk3036_vop_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_win_phy rk3126_win1_data = {
> @@ -213,6 +215,8 @@ static const struct vop_data rk3126_vop = {
> .output = _output,
> .win = rk3126_vop_win_data,
> .win_size = ARRAY_SIZE(rk3126_vop_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const int px30_vop_intrs[] = {
> @@ -340,6 +344,8 @@ static const struct vop_data px30_vop_big = {
> .output = _output,
> .win = px30_vop_big_win_data,
> .win_size = ARRAY_SIZE(px30_vop_big_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_win_data px30_vop_lit_win_data[] = {
> @@ -356,6 +362,8 @@ static const struct vop_data px30_vop_lit = {
> .output = _output,
> .win = px30_vop_lit_win_data,
> .win_size = ARRAY_SIZE(px30_vop_lit_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_scl_regs rk3066_win_scl = {
> @@ -479,6 +487,8 @@ static const struct vop_data rk3066_vop = {
> .output = _output,
> .win = rk3066_vop_win_data,
> .win_size = ARRAY_SIZE(rk3066_vop_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_scl_regs rk3188_win_scl = {
> @@ -585,6 +595,8 @@ static const struct vop_data rk3188_vop = {
> .win = rk3188_vop_win_data,
> .win_size = ARRAY_SIZE(rk3188_vop_win_data),
> .feature =
Re: [PATCH] drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()
On 2/7/23 11:33, Asahi Lina wrote:
> On 07/02/2023 03.47, Javier Martinez Canillas wrote:
>> Hello Lina,
>>
>> On 2/5/23 13:51, Asahi Lina wrote:
>>> Other functions touching shmem->sgt take the pages lock, so do that here
>>> too. drm_gem_shmem_get_pages() & co take the same lock, so move to the
>>> _locked() variants to avoid recursive locking.
>>>
>>> Discovered while auditing locking to write the Rust abstractions.
>>>
>>> Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
>>> Fixes: 4fa3d66f132b ("drm/shmem: Do dma_unmap_sg before purging pages")
>>> Signed-off-by: Asahi Lina
>>> ---
>>
>> Good catch. The patch looks good to me.
>>
>> Reviewed-by: Javier Martinez Canillas
>>
>> What about drm_gem_shmem_free() BTW, I believe that the helper should also
>> grab the lock before unmap / free the sgtable?
>
> That's called from driver free callbacks, so it should only be called
> when there are no other users left and the refcount is zero, right? If
> there's anyone else racing it I think we have bigger problems than the
> pages lock at that point, since the last thing it does is `kfree(shmem);` ^^
>
Yes, I was wondering only for the critical section that does:
if (shmem->sgt) {
dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
DMA_BIDIRECTIONAL, 0);
sg_free_table(shmem->sgt);
kfree(shmem->sgt);
}
if (shmem->pages)
drm_gem_shmem_put_pages(shmem);
> (In Rust terms this is equivalent to the Drop trait, which takes a
> mutable/exclusive reference, which means no other reference to the
> object can exist at that point, so no races are possible. And in fact in
> my Rust abstraction I trigger a drop of the Rust object embedded in the
> shmem object before calling drm_gem_shmem_free(), so if this invariant
> doesn't hold that code would be wrong too!)
>
But I guess you are correct and would be safe to assume that the .free
callback won't race against other struct drm_gem_object_funcs handlers.
I just felt to ask since wasn't sure about that.
I'll wait a few days in case someone else wants to take a look to your
patch and then push it to drm-misc. Thanks again!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [Intel-gfx] [PATCH v2] drm/i915/pcode: Give the punit time to settle before fatally failing
Hi Andrzej, > > During module load the punit might still be busy with its booting > > routines. During this time we try to communicate with it but we > > fail because we don't receive any feedback from it and we return > > immediately with a -EINVAL fatal error. > > > > At this point the driver load is "dramatically" aborted. The > > following error message notifies us about it. > > > > i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3) > > > > It would be enough to wait a little in order to give the punit > > the chance to come up bright and shiny, ready to interact with > > the driver. > > > > Wait up 10 seconds for the punit to settle and complete any > > outstanding transactions upon module load. If it still fails try > > again with a longer timeout, 180s, 3 minutes. If it still fails > > then return -EPROBE_DEFER, in order to give the punit a second > > chance. > > > > Even if these timers might look long, we should consider that the > > punit, depending on the platforms, might need long times to > > complete its routines. Besides we want to try anything possible > > to move forward before deciding to abort the driver's load. > > > > The issue has been reported in: > > > > https://gitlab.freedesktop.org/drm/intel/-/issues/7814 > > > > The changes in this patch are valid only and uniquely during > > boot. The common transactions with the punit during the driver's > > normal operation are not affected. > > > > Signed-off-by: Aravind Iddamsetty > > Co-developed-by: Chris Wilson > > Signed-off-by: Chris Wilson > > Signed-off-by: Andi Shyti > > Cc: Rodrigo Vivi > > With improved commit message it looks OK for me. There is still question why > it takes so long for punit to become ready. It's hardware and some punit operations require that much. There are some documents floating around that have all these calculations. Some devices require even more time and, after consulting with hardware guys, Aravind had to increase the timeout to 6 minutes! Boot routines should not require this much, thus the 20 seconds. > Anyway: > Reviewed-by: Andrzej Hajda Thanks a lot for looking into this, Andrzej! Andi
Re: [PATCH] drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()
On 07/02/2023 03.47, Javier Martinez Canillas wrote:
> Hello Lina,
>
> On 2/5/23 13:51, Asahi Lina wrote:
>> Other functions touching shmem->sgt take the pages lock, so do that here
>> too. drm_gem_shmem_get_pages() & co take the same lock, so move to the
>> _locked() variants to avoid recursive locking.
>>
>> Discovered while auditing locking to write the Rust abstractions.
>>
>> Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
>> Fixes: 4fa3d66f132b ("drm/shmem: Do dma_unmap_sg before purging pages")
>> Signed-off-by: Asahi Lina
>> ---
>
> Good catch. The patch looks good to me.
>
> Reviewed-by: Javier Martinez Canillas
>
> What about drm_gem_shmem_free() BTW, I believe that the helper should also
> grab the lock before unmap / free the sgtable?
That's called from driver free callbacks, so it should only be called
when there are no other users left and the refcount is zero, right? If
there's anyone else racing it I think we have bigger problems than the
pages lock at that point, since the last thing it does is `kfree(shmem);` ^^
(In Rust terms this is equivalent to the Drop trait, which takes a
mutable/exclusive reference, which means no other reference to the
object can exist at that point, so no races are possible. And in fact in
my Rust abstraction I trigger a drop of the Rust object embedded in the
shmem object before calling drm_gem_shmem_free(), so if this invariant
doesn't hold that code would be wrong too!)
~~ Lina
Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add GPIO display mux binding
Hi Laurent,
On Tue, Feb 7, 2023 at 6:25 PM Laurent Pinchart
wrote:
>
> On Tue, Feb 07, 2023 at 06:07:44PM +0800, Pin-yen Lin wrote:
> > On Wed, Jan 18, 2023 at 4:17 AM Rob Herring wrote:
> > > On Mon, Jan 16, 2023 at 07:08:19PM +0800, Pin-yen Lin wrote:
> > > > From: Nicolas Boichat
> > > >
> > > > Add bindings for Generic GPIO mux driver.
> > > >
> > > > Signed-off-by: Nicolas Boichat
> > > > Signed-off-by: Pin-yen Lin
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Referenced existing dt-binding schemas from graph.yaml
> > > > - Added ddc-i2c-bus into the bindings
> > > >
> > > > .../bindings/display/bridge/gpio-mux.yaml | 95 +++
> > > > 1 file changed, 95 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > > > b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > > > new file mode 100644
> > > > index ..da29ba078f05
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > > > @@ -0,0 +1,95 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Generic display mux (1 input, 2 outputs)
> > > > +
> > > > +maintainers:
> > > > + - Nicolas Boichat
> > > > +
> > > > +description: |
> > > > + This bindings describes a simple display (e.g. HDMI) mux, that has 1
> > > > + input, and 2 outputs. The mux status is controlled by hardware, and
> > > > + its status is read back using a GPIO.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > +const: gpio-display-mux
> > > > +
> > > > + detect-gpios:
> > > > +maxItems: 1
> > > > +description: GPIO that indicates the active output
> > >
> > > What are we detecting? That implies an input, but this is selecting the
> > > output path, right? Or what does 'mux status is controlled by hardware'
> > > mean exactly? Something else? That does not sound very generic.
> >
> > The GPIO (or any kind of MUX) is an input that indicates where the
> > output should go. The actual "output selection" procedure is done in
> > the driver. That is, the driver monitors this GPIO and selects the
> > output path accordingly. In our use case, the GPIO is reported by the
> > embedded controller on the device.
> >
> > [1] listed other similar bridges that can leverage this driver, so we
> > called this driver "generic".
> >
> > [1]:
> > https://lore.kernel.org/all/CAJMQK-jGw8kJFNjoHjeZUL+3NCiOS2hgGERnAnMwNsL_cm_J=q...@mail.gmail.com/
> >
> > > In any case, we have a common mux binding so any kind of mux control
> > > could be used here, not just GPIO. Then you can make this just a generic
> > > display mux.
> >
> > Thanks for sharing this, I'll update the binding in the next version.
> >
> > > > +
> > > > + ddc-i2c-bus:
> > > > +description: phandle link to the I2C controller used for DDC EDID
> > > > probing
> > > > +$ref: /schemas/types.yaml#/definitions/phandle
> > >
> > > This belongs in the connector node(s).
> >
> > The HDMI bridge before the MUX doesn't (and doesn't have to) know that
> > its next bridge is a MUX. We put it here so that the HDMI bridge can
> > parse the phandle and get the bus node.
>
> How does that work, does the HDMI encoder driver parse the ddc-i2c-bus
> property of the next DT node in the OF graph ?
Yes. In our use case, mtk_hdmi.c[2] checks the remote node of its
output port to get the bus phandle. sun4i_hdmi_enc.c[3] seems to use a
similar approach as well.
[2]:
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/mediatek/mtk_hdmi.c#L1500
[3]:
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c#L240
Regards,
Pin-yen
>
> > > > +
> > > > + ports:
> > > > +$ref: /schemas/graph.yaml#/properties/ports
> > > > +
> > > > +properties:
> > > > + port@0:
> > > > +$ref: /schemas/graph.yaml#/properties/port
> > > > +description: |
> > > > + Video port for input.
> > > > +
> > > > + port@1:
> > > > +$ref: /schemas/graph.yaml#/properties/port
> > > > +description: |
> > > > + 2 video ports for output.
> > > > + The reg value in the endpoints matches the GPIO status: when
> > > > + GPIO is asserted, endpoint with reg value <1> is selected.
> > > > +
> > > > +required:
> > > > + - port@0
> > > > + - port@1
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - detect-gpios
> > > > + - ports
> > > > +
> > > > +unevaluatedProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > +#include
> > > > +hdmi_mux: hdmi_mux {
> > > > + compatible = "gpio-display-mux";
> > > > +
Re: [Intel-gfx] [PATCH v3 2/2] drm/probe_helper: sort out poll_running vs poll_enabled
Hi Dmitry,
On Tue, 24 Jan 2023, Dmitry Baryshkov wrote:
There are two flags attemting to guard connector polling:
poll_enabled and poll_running. While poll_enabled semantics is clearly
defined and fully adhered (mark that drm_kms_helper_poll_init() was
called and not finalized by the _fini() call), the poll_running flag
doesn't have such clearliness.
This flag is used only in drm_helper_probe_single_connector_modes() to
guard calling of drm_kms_helper_poll_enable, it doesn't guard the
drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
is actually running. Tie HPD enablement to this flag.
This fixes the following warning reported after merging the HPD series:
Hot plug detection already enabled
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257
drm_bridge_hpd_enable+0x94/0x9c [drm]
Modules linked in: videobuf2_memops snd_soc_simple_card
snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common snd_soc_imx_spdif
adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
Hardware name: NXP i.MX8MQ EVK (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
sp : 89ef3740
x29: 89ef3740 x28: 09331f00 x27: 1000
x26: 0020 x25: 81148ed8 x24: 0a8fe000
x23: fffd x22: 05086348 x21: 81133ee0
x20: 0550d800 x19: 05086288 x18: 0006
x17: x16: 896ef008 x15: 972891004260
x14: 2a1403e19400 x13: 972891004260 x12: 2a1403e19400
x11: 7100385f29400801 x10: 0aa0 x9 : 88112744
x8 : 00250b00 x7 : 0003 x6 : 0011
x5 : x4 : bd986a48 x3 : 0001
x2 : x1 : x0 : 0025
Call trace:
drm_bridge_hpd_enable+0x94/0x9c [drm]
drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
drm_client_modeset_probe+0x204/0x1190 [drm]
__drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
dcss_kms_attach+0x1c8/0x254 [imx_dcss]
dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
platform_probe+0x70/0xcc
really_probe+0xc4/0x2e0
__driver_probe_device+0x80/0xf0
driver_probe_device+0xe0/0x164
__device_attach_driver+0xc0/0x13c
bus_for_each_drv+0x84/0xe0
__device_attach+0xa4/0x1a0
device_initial_probe+0x1c/0x30
bus_probe_device+0xa4/0xb0
deferred_probe_work_func+0x90/0xd0
process_one_work+0x200/0x474
worker_thread+0x74/0x43c
kthread+0xfc/0x110
ret_from_fork+0x10/0x20
---[ end trace ]---
Reported-by: Laurentiu Palcu
Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
Tested-by: Marek Szyprowski
Tested-by: Chen-Yu Tsai
Acked-by: Laurentiu Palcu
Tested-by: Laurentiu Palcu
Tested-by: Laurent Pinchart
Signed-off-by: Dmitry Baryshkov
Thanks for your patch!
This gets rids of the warning splats on e.g. Renesas Koelsch and
Salvator-XS, so
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add GPIO display mux binding
On Tue, Feb 07, 2023 at 06:07:44PM +0800, Pin-yen Lin wrote:
> On Wed, Jan 18, 2023 at 4:17 AM Rob Herring wrote:
> > On Mon, Jan 16, 2023 at 07:08:19PM +0800, Pin-yen Lin wrote:
> > > From: Nicolas Boichat
> > >
> > > Add bindings for Generic GPIO mux driver.
> > >
> > > Signed-off-by: Nicolas Boichat
> > > Signed-off-by: Pin-yen Lin
> > > ---
> > >
> > > Changes in v2:
> > > - Referenced existing dt-binding schemas from graph.yaml
> > > - Added ddc-i2c-bus into the bindings
> > >
> > > .../bindings/display/bridge/gpio-mux.yaml | 95 +++
> > > 1 file changed, 95 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > > new file mode 100644
> > > index ..da29ba078f05
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > > @@ -0,0 +1,95 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Generic display mux (1 input, 2 outputs)
> > > +
> > > +maintainers:
> > > + - Nicolas Boichat
> > > +
> > > +description: |
> > > + This bindings describes a simple display (e.g. HDMI) mux, that has 1
> > > + input, and 2 outputs. The mux status is controlled by hardware, and
> > > + its status is read back using a GPIO.
> > > +
> > > +properties:
> > > + compatible:
> > > +const: gpio-display-mux
> > > +
> > > + detect-gpios:
> > > +maxItems: 1
> > > +description: GPIO that indicates the active output
> >
> > What are we detecting? That implies an input, but this is selecting the
> > output path, right? Or what does 'mux status is controlled by hardware'
> > mean exactly? Something else? That does not sound very generic.
>
> The GPIO (or any kind of MUX) is an input that indicates where the
> output should go. The actual "output selection" procedure is done in
> the driver. That is, the driver monitors this GPIO and selects the
> output path accordingly. In our use case, the GPIO is reported by the
> embedded controller on the device.
>
> [1] listed other similar bridges that can leverage this driver, so we
> called this driver "generic".
>
> [1]:
> https://lore.kernel.org/all/CAJMQK-jGw8kJFNjoHjeZUL+3NCiOS2hgGERnAnMwNsL_cm_J=q...@mail.gmail.com/
>
> > In any case, we have a common mux binding so any kind of mux control
> > could be used here, not just GPIO. Then you can make this just a generic
> > display mux.
>
> Thanks for sharing this, I'll update the binding in the next version.
>
> > > +
> > > + ddc-i2c-bus:
> > > +description: phandle link to the I2C controller used for DDC EDID
> > > probing
> > > +$ref: /schemas/types.yaml#/definitions/phandle
> >
> > This belongs in the connector node(s).
>
> The HDMI bridge before the MUX doesn't (and doesn't have to) know that
> its next bridge is a MUX. We put it here so that the HDMI bridge can
> parse the phandle and get the bus node.
How does that work, does the HDMI encoder driver parse the ddc-i2c-bus
property of the next DT node in the OF graph ?
> > > +
> > > + ports:
> > > +$ref: /schemas/graph.yaml#/properties/ports
> > > +
> > > +properties:
> > > + port@0:
> > > +$ref: /schemas/graph.yaml#/properties/port
> > > +description: |
> > > + Video port for input.
> > > +
> > > + port@1:
> > > +$ref: /schemas/graph.yaml#/properties/port
> > > +description: |
> > > + 2 video ports for output.
> > > + The reg value in the endpoints matches the GPIO status: when
> > > + GPIO is asserted, endpoint with reg value <1> is selected.
> > > +
> > > +required:
> > > + - port@0
> > > + - port@1
> > > +
> > > +required:
> > > + - compatible
> > > + - detect-gpios
> > > + - ports
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +examples:
> > > + - |
> > > +#include
> > > +hdmi_mux: hdmi_mux {
> > > + compatible = "gpio-display-mux";
> > > + detect-gpios = < 36 GPIO_ACTIVE_HIGH>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_mux_pins>;
> > > + ddc-i2c-bus = <>;
> > > +
> > > + ports {
> > > +#address-cells = <1>;
> > > +#size-cells = <0>;
> > > +
> > > +port@0 { /* input */
> > > + reg = <0>;
> > > +
> > > + hdmi_mux_in: endpoint {
> > > +remote-endpoint = <_out>;
> > > + };
> > > +};
> > > +
> > > +port@1 { /* output */
> > > + reg = <1>;
> > > +
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + hdmi_mux_out_anx: endpoint@0 {
> > > +reg =
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
Hi Neil,
On Tue, Feb 7, 2023 at 11:02 AM Geert Uytterhoeven wrote:
> On Tue, Feb 7, 2023 at 10:59 AM Neil Armstrong
> wrote:
> > On 07/02/2023 10:40, Geert Uytterhoeven wrote:
> > > On Tue, Jan 10, 2023 at 5:37 PM Dmitry Baryshkov
> > > wrote:
> > >> On 10/01/2023 08:57, Laurentiu Palcu wrote:
> > >>> On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
> > On 09/01/2023 18:21, Laurentiu Palcu wrote:
> > > It looks like there are some issues with this patchset... :/ I just
> > > fetched the drm-tip and, with these patches included, the "Hot plug
> > > detection already enabled" warning is back for i.MX DCSS.
> >
> > Could you please provide a backtrace?
> > >>>
> > >>> Sure, see below:
> > >>
> > >> I wondered, why didn't I see this on msm, my main target nowadays. The
> > >> msm driver is calling msm_kms_helper_poll_init() after initializing
> > >> fbdev, so all previous kms_helper_poll_enable() calls return early.
> > >>
> > >> I think I have the fix ready. Let me test it locally before posting.
> > >
> > > Is this fix available?
> > > Do you have a lore link?
> >
> > The fix at [1] has been applied on 2023-01-26
> >
> > [1]
> > https://lore.kernel.org/all/20230124104548.3234554-1-dmitry.barysh...@linaro.org/
>
> Applied where? linux-next does not have it.
commit cbf143b282c64e59
("drm/probe_helper: extract two helper functions") in next-20230127
next-20230130 next-20230131
commit d33a54e3991dfce8
("drm/probe_helper: sort out poll_running vs poll_enabled") in
next-20230127 next-20230130 next-20230131
but not in any later version?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
On 07/02/2023 11:02, Geert Uytterhoeven wrote:
Hi Neil,
On Tue, Feb 7, 2023 at 10:59 AM Neil Armstrong
wrote:
On 07/02/2023 10:40, Geert Uytterhoeven wrote:
On Tue, Jan 10, 2023 at 5:37 PM Dmitry Baryshkov
wrote:
On 10/01/2023 08:57, Laurentiu Palcu wrote:
On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
On 09/01/2023 18:21, Laurentiu Palcu wrote:
It looks like there are some issues with this patchset... :/ I just
fetched the drm-tip and, with these patches included, the "Hot plug
detection already enabled" warning is back for i.MX DCSS.
Could you please provide a backtrace?
Sure, see below:
I wondered, why didn't I see this on msm, my main target nowadays. The
msm driver is calling msm_kms_helper_poll_init() after initializing
fbdev, so all previous kms_helper_poll_enable() calls return early.
I think I have the fix ready. Let me test it locally before posting.
Is this fix available?
Do you have a lore link?
The fix at [1] has been applied on 2023-01-26
[1]
https://lore.kernel.org/all/20230124104548.3234554-1-dmitry.barysh...@linaro.org/
Applied where? linux-next does not have it.
On drm-misc-next, it should have been send to drm-misc, but it seems the last PR
to drm-misc was sent without those:
https://cgit.freedesktop.org/drm/drm-misc/tag/?h=drm-misc-next-2023-01-26
Thomas, Maxime, is it too late to get those into v6.3 ? I did apply them before
rc6.
Neil
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v9 0/9] Register Type-C mode-switch in DP bridge endpoints
Hi Lyude, Thanks for letting me know! I just sent out a v11 and already received some review comments, but reviews are always welcomed if you have time to take a look. Regards, Pin-yen On Tue, Jan 31, 2023 at 7:10 AM Lyude Paul wrote: > > Don't know if this still needs reviews from me (feel free to respond if it > does!), but I wanted to say nice work! This is something I've wanted to see > added to DRM for a while ♥ > > > On Mon, 2023-01-09 at 16:40 +0800, Pin-yen Lin wrote: > > This series introduces bindings for anx7625/it6505 to register Type-C > > mode-switch in their output endpoints, and use data-lanes property to > > describe the pin connections. > > > > The first two patch modifies fwnode_graph_devcon_matches and > > cros_typec_init_ports to enable the registration of the switches. > > > > Patch 4~6 introduce the bindings for anx7625 and the corresponding driver > > modifications. > > > > Patch 7~9 add similar bindings and driver changes for it6505. > > > > v7: > > https://lore.kernel.org/all/20230105132457.4125372-1-treapk...@chromium.org/ > > v6: > > https://lore.kernel.org/all/20221124102056.393220-1-treapk...@chromium.org/ > > v5: > > https://lore.kernel.org/linux-usb/20220622173605.1168416-1-pmal...@chromium.org/ > > > > Changes in v9: > > - Collected Reviewed-by tag > > - Fixed subject prefix again > > - Changed the naming of the example node for it6505 > > > > Changes in v8: > > - Fixed the build issue when CONFIG_TYPEC=m > > - Fixed some style issues > > - Fixed the subject prefixes for the bindings patch > > - Fixed the bindings for data-lanes properties > > > > Changes in v7: > > - Fix the long comment lines > > - Extracted the common codes to a helper function > > - Fixed style issues in anx7625 driver > > - Removed DT property validation in anx7625 driver. > > - Fixed style issues in it6505 driver > > - Removed the redundant sleep in it6505 driver > > - Removed DT property validation in it6505 driver > > - Rebased to drm-misc-next > > - Fixed indentations in bindings patches > > - Added a new patch to fix indentations in Kconfig > > > > Changes in v6: > > - Changed it6505_typec_mux_set callback function to accommodate with > > the latest drm-misc patches > > - Changed the driver implementation to accommodate with the new binding > > - Dropped typec-switch binding and use endpoints and data-lanes properties > > to describe the pin connections > > - Added new patches (patch 1,2,4) to fix probing issues > > - Changed the bindings of it6505/anx7625 and modified the drivers > > accordingly > > - Merged it6505/anx7625 driver changes into a single patch > > > > Pin-yen Lin (7): > > drm/display: Add Type-C switch helpers > > dt-bindings: display: bridge: anx7625: Add mode-switch support > > drm/bridge: anx7625: Check for Type-C during panel registration > > drm/bridge: anx7625: Register Type C mode switches > > dt-bindings: display: bridge: it6505: Add mode-switch support > > drm/bridge: it6505: Fix Kconfig indentation > > drm/bridge: it6505: Register Type C mode switches > > > > Prashant Malani (2): > > device property: Add remote endpoint to devcon matcher > > platform/chrome: cros_ec_typec: Purge blocking switch devlinks > > > > .../display/bridge/analogix,anx7625.yaml | 99 - > > .../bindings/display/bridge/ite,it6505.yaml | 93 ++-- > > drivers/base/property.c | 15 ++ > > drivers/gpu/drm/bridge/Kconfig| 21 +-- > > drivers/gpu/drm/bridge/analogix/Kconfig | 1 + > > drivers/gpu/drm/bridge/analogix/anx7625.c | 101 +- > > drivers/gpu/drm/bridge/analogix/anx7625.h | 13 ++ > > drivers/gpu/drm/bridge/ite-it6505.c | 119 +++- > > drivers/gpu/drm/display/drm_dp_helper.c | 132 ++ > > drivers/platform/chrome/cros_ec_typec.c | 10 ++ > > include/drm/display/drm_dp_helper.h | 16 +++ > > 11 files changed, 591 insertions(+), 29 deletions(-) > > > > -- > Cheers, > Lyude Paul (she/her) > Software Engineer at Red Hat >
Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add GPIO display mux binding
Hi Rob,
Thanks for the review.
On Wed, Jan 18, 2023 at 4:17 AM Rob Herring wrote:
>
> On Mon, Jan 16, 2023 at 07:08:19PM +0800, Pin-yen Lin wrote:
> > From: Nicolas Boichat
> >
> > Add bindings for Generic GPIO mux driver.
> >
> > Signed-off-by: Nicolas Boichat
> > Signed-off-by: Pin-yen Lin
> > ---
> >
> > Changes in v2:
> > - Referenced existing dt-binding schemas from graph.yaml
> > - Added ddc-i2c-bus into the bindings
> >
> > .../bindings/display/bridge/gpio-mux.yaml | 95 +++
> > 1 file changed, 95 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > new file mode 100644
> > index ..da29ba078f05
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
> > @@ -0,0 +1,95 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Generic display mux (1 input, 2 outputs)
> > +
> > +maintainers:
> > + - Nicolas Boichat
> > +
> > +description: |
> > + This bindings describes a simple display (e.g. HDMI) mux, that has 1
> > + input, and 2 outputs. The mux status is controlled by hardware, and
> > + its status is read back using a GPIO.
> > +
> > +properties:
> > + compatible:
> > +const: gpio-display-mux
> > +
> > + detect-gpios:
> > +maxItems: 1
> > +description: GPIO that indicates the active output
>
> What are we detecting? That implies an input, but this is selecting the
> output path, right? Or what does 'mux status is controlled by hardware'
> mean exactly? Something else? That does not sound very generic.
The GPIO (or any kind of MUX) is an input that indicates where the
output should go. The actual "output selection" procedure is done in
the driver. That is, the driver monitors this GPIO and selects the
output path accordingly. In our use case, the GPIO is reported by the
embedded controller on the device.
[1] listed other similar bridges that can leverage this driver, so we
called this driver "generic".
[1]:
https://lore.kernel.org/all/CAJMQK-jGw8kJFNjoHjeZUL+3NCiOS2hgGERnAnMwNsL_cm_J=q...@mail.gmail.com/
>
> In any case, we have a common mux binding so any kind of mux control
> could be used here, not just GPIO. Then you can make this just a generic
> display mux.
Thanks for sharing this, I'll update the binding in the next version.
>
> > +
> > + ddc-i2c-bus:
> > +description: phandle link to the I2C controller used for DDC EDID
> > probing
> > +$ref: /schemas/types.yaml#/definitions/phandle
>
> This belongs in the connector node(s).
The HDMI bridge before the MUX doesn't (and doesn't have to) know that
its next bridge is a MUX. We put it here so that the HDMI bridge can
parse the phandle and get the bus node.
Regards,
Pin-yen
>
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: |
> > + Video port for input.
> > +
> > + port@1:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: |
> > + 2 video ports for output.
> > + The reg value in the endpoints matches the GPIO status: when
> > + GPIO is asserted, endpoint with reg value <1> is selected.
> > +
> > +required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - detect-gpios
> > + - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +hdmi_mux: hdmi_mux {
> > + compatible = "gpio-display-mux";
> > + detect-gpios = < 36 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_mux_pins>;
> > + ddc-i2c-bus = <>;
> > +
> > + ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 { /* input */
> > + reg = <0>;
> > +
> > + hdmi_mux_in: endpoint {
> > +remote-endpoint = <_out>;
> > + };
> > +};
> > +
> > +port@1 { /* output */
> > + reg = <1>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + hdmi_mux_out_anx: endpoint@0 {
> > +reg = <0>;
> > +remote-endpoint = <_bridge_in>;
> > + };
> > +
> > + hdmi_mux_out_hdmi: endpoint@1 {
> > +reg = <1>;
> > +remote-endpoint = <_connector_in>;
> > + };
> > +};
> > + };
> > +};
> > --
> > 2.39.0.314.g84b9a713c41-goog
> >
[PATCH] dt-bindings: display: panel: visionox,vtdr6130: add missing reg property
Add missing reg property and update example to add dsi top node.
Fixes: ef85db911134 ("dt-bindings: display: panel: document the Visionox
VTDR6130 AMOLED DSI Panel")
Signed-off-by: Neil Armstrong
---
.../bindings/display/panel/visionox,vtdr6130.yaml | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
index 49e2fd4b4e99..84562a5b710a 100644
--- a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
+++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
@@ -16,6 +16,10 @@ properties:
compatible:
const: visionox,vtdr6130
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
vddio-supply: true
vci-supply: true
vdd-supply: true
@@ -26,6 +30,7 @@ additionalProperties: false
required:
- compatible
+ - reg
- vddio-supply
- vci-supply
- vdd-supply
@@ -35,18 +40,23 @@ required:
examples:
- |
#include
-panel {
-compatible = "visionox,vtdr6130";
-
-vddio-supply = <_l12b_1p8>;
-vci-supply = <_l13b_3p0>;
-vdd-supply = <_l11b_1p2>;
-
-reset-gpios = < 133 GPIO_ACTIVE_LOW>;
-
-port {
-panel0_in: endpoint {
-remote-endpoint = <_out>;
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "visionox,vtdr6130";
+reg = <0>;
+
+vddio-supply = <_l12b_1p8>;
+vci-supply = <_l13b_3p0>;
+vdd-supply = <_l11b_1p2>;
+
+reset-gpios = < 133 GPIO_ACTIVE_LOW>;
+
+port {
+panel0_in: endpoint {
+remote-endpoint = <_out>;
+};
};
};
};
---
base-commit: 49a8133221c71b935f36a7c340c0271c2a9ee2db
change-id: 20230207-topic-sm8550-upstream-vtdr6130-bindings-fix-a1d2630efc06
Best regards,
--
Neil Armstrong
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
Hi Neil,
On Tue, Feb 7, 2023 at 10:59 AM Neil Armstrong
wrote:
> On 07/02/2023 10:40, Geert Uytterhoeven wrote:
> > On Tue, Jan 10, 2023 at 5:37 PM Dmitry Baryshkov
> > wrote:
> >> On 10/01/2023 08:57, Laurentiu Palcu wrote:
> >>> On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
> On 09/01/2023 18:21, Laurentiu Palcu wrote:
> > It looks like there are some issues with this patchset... :/ I just
> > fetched the drm-tip and, with these patches included, the "Hot plug
> > detection already enabled" warning is back for i.MX DCSS.
>
> Could you please provide a backtrace?
> >>>
> >>> Sure, see below:
> >>
> >> I wondered, why didn't I see this on msm, my main target nowadays. The
> >> msm driver is calling msm_kms_helper_poll_init() after initializing
> >> fbdev, so all previous kms_helper_poll_enable() calls return early.
> >>
> >> I think I have the fix ready. Let me test it locally before posting.
> >
> > Is this fix available?
> > Do you have a lore link?
>
> The fix at [1] has been applied on 2023-01-26
>
> [1]
> https://lore.kernel.org/all/20230124104548.3234554-1-dmitry.barysh...@linaro.org/
Applied where? linux-next does not have it.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
Hi Geert,
On 07/02/2023 10:40, Geert Uytterhoeven wrote:
Hi Dmitry,
On Tue, Jan 10, 2023 at 5:37 PM Dmitry Baryshkov
wrote:
On 10/01/2023 08:57, Laurentiu Palcu wrote:
On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
On 09/01/2023 18:21, Laurentiu Palcu wrote:
It looks like there are some issues with this patchset... :/ I just
fetched the drm-tip and, with these patches included, the "Hot plug
detection already enabled" warning is back for i.MX DCSS.
Could you please provide a backtrace?
Sure, see below:
I wondered, why didn't I see this on msm, my main target nowadays. The
msm driver is calling msm_kms_helper_poll_init() after initializing
fbdev, so all previous kms_helper_poll_enable() calls return early.
I think I have the fix ready. Let me test it locally before posting.
Is this fix available?
Do you have a lore link?
The fix at [1] has been applied on 2023-01-26
[1]
https://lore.kernel.org/all/20230124104548.3234554-1-dmitry.barysh...@linaro.org/
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
On Tue, Jan 10, 2023 at 11:20 AM Geert Uytterhoeven
wrote:
> On Tue, Jan 10, 2023 at 8:07 AM Laurentiu Palcu
> wrote:
> > On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
> > > On 09/01/2023 18:21, Laurentiu Palcu wrote:
> > > > It looks like there are some issues with this patchset... :/ I just
> > > > fetched the drm-tip and, with these patches included, the "Hot plug
> > > > detection already enabled" warning is back for i.MX DCSS.
> > >
> > > Could you please provide a backtrace?
> >
> > Sure, see below:
> >
> > [ cut here ]
> > Hot plug detection already enabled
> > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257
> > drm_bridge_hpd_enable+0x94/0x9c [drm]
> > Modules linked in: videobuf2_memops snd_soc_simple_card
> > snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common
> > snd_soc_imx_spdif adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
> > CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578
> > #6
> > Hardware name: NXP i.MX8MQ EVK (DT)
> > Workqueue: events_unbound deferred_probe_work_func
> > pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
> > lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
> > sp : 89ef3740
> > x29: 89ef3740 x28: 09331f00 x27: 1000
> > x26: 0020 x25: 81148ed8 x24: 0a8fe000
> > x23: fffd x22: 05086348 x21: 81133ee0
> > x20: 0550d800 x19: 05086288 x18: 0006
> > x17: x16: 896ef008 x15: 972891004260
> > x14: 2a1403e19400 x13: 972891004260 x12: 2a1403e19400
> > x11: 7100385f29400801 x10: 0aa0 x9 : 88112744
> > x8 : 00250b00 x7 : 0003 x6 : 0011
> > x5 : x4 : bd986a48 x3 : 0001
> > x2 : x1 : x0 : 0025
> > Call trace:
> > drm_bridge_hpd_enable+0x94/0x9c [drm]
> > drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
> > drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
> > drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
> > drm_client_modeset_probe+0x204/0x1190 [drm]
> > __drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
> > drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
> > drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
> > drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
> > dcss_kms_attach+0x1c8/0x254 [imx_dcss]
> > dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
> > platform_probe+0x70/0xcc
> > really_probe+0xc4/0x2e0
> > __driver_probe_device+0x80/0xf0
> > driver_probe_device+0xe0/0x164
> > __device_attach_driver+0xc0/0x13c
> > bus_for_each_drv+0x84/0xe0
> > __device_attach+0xa4/0x1a0
> > device_initial_probe+0x1c/0x30
> > bus_probe_device+0xa4/0xb0
> > deferred_probe_work_func+0x90/0xd0
> > process_one_work+0x200/0x474
> > worker_thread+0x74/0x43c
> > kthread+0xfc/0x110
> > ret_from_fork+0x10/0x20
> > ---[ end trace ]---
>
> I get a similar trace on R-Car Gen2 (Koelsch with R-Car M2-W) and
> Gen3 (Salvator-XS with R-Car H3 ES2.0), and bisected it to commit
> 92d755d8f13b6791 ("drm/bridge_connector: rely on drm_kms_helper_poll_*
> for HPD enablement") in drm-misc/for-linux-next.
>
> As I do not have any displays connected, I do not know what is the
> full impact.
FTR, the issue is still present.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically
Hi Dmitry,
On Tue, Jan 10, 2023 at 5:37 PM Dmitry Baryshkov
wrote:
> On 10/01/2023 08:57, Laurentiu Palcu wrote:
> > On Mon, Jan 09, 2023 at 10:26:28PM +0200, Dmitry Baryshkov wrote:
> >> On 09/01/2023 18:21, Laurentiu Palcu wrote:
> >>> It looks like there are some issues with this patchset... :/ I just
> >>> fetched the drm-tip and, with these patches included, the "Hot plug
> >>> detection already enabled" warning is back for i.MX DCSS.
> >>
> >> Could you please provide a backtrace?
> >
> > Sure, see below:
>
> I wondered, why didn't I see this on msm, my main target nowadays. The
> msm driver is calling msm_kms_helper_poll_init() after initializing
> fbdev, so all previous kms_helper_poll_enable() calls return early.
>
> I think I have the fix ready. Let me test it locally before posting.
Is this fix available?
Do you have a lore link?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
