On Fri, Jan 13, 2023 at 2:19 PM Linux kernel regression tracking
(Thorsten Leemhuis) wrote:
>
> [CCing Daniel]
>
> On 05.01.23 13:28, Thorsten Leemhuis wrote:
> > [adding Karol and Lyude to the list of recipients]
> >
> > On 28.12.22 15:49, Diogo Ivo wrote:
> >> Hello,
> >>
> >> Commit 2541626cfb7
On 14/01/2023 01:00, Richard Acayan wrote:
> These panels communicate brightness in big endian. This is not a quirk
> of the panels themselves, but rather, a part of the MIPI standard. Use
> the new mipi_dsi_dcs_set_display_brightness_wide() function that
> properly handles 16-bit brightness ins
On 1/13/2023 01:22, Tvrtko Ursulin wrote:
On 12/01/2023 20:59, John Harrison wrote:
On 1/12/2023 02:15, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reas
On 1/2/2023 7:47 AM, Dmitry Baryshkov wrote:
The frame event callback is always set to dpu_crtc_frame_event_cb() (or
to NULL) and the data is always either the CRTC itself or NULL
(correpondingly). Thus drop the event callback registration, call the
dpu_crtc_frame_event_cb() directly and gate
On 1/2/2023 7:47 AM, Dmitry Baryshkov wrote:
Struct dpu_encoder_virt_ops is used to provide several callbacks to the
phys_enc backends. However these ops are static and are not supposed to
change in the foreseeble future. Drop the indirection and call
corresponding functions directly.
Revie
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.
That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/
Set the "pre_enable_prev_first" as provided by commit 4fb912e5e190
("drm/bridge: Introduce pre_enable_prev_first to alter bridge init
order"). This should allow us to revert commit ec7981e6c614
("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and
commit 7d8e9a90509f ("drm/msm/dsi: m
On 1/13/23 13:05, John Paul Adrian Glaubitz wrote:
> Hi Rob!
>
> On 1/13/23 20:11, Rob Landley wrote:
>> There is definitely interest in this architecture. I'm aware Rich hasn't been
>> the most responsive maintainer. (I'm told he's on vacation with his family at
>> the moment, according to the te
On 2023-01-13 18:00, Chen, Xiaogang wrote:
On 1/13/2023 4:26 PM, Felix Kuehling wrote:
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable pr
On 1/13/2023 4:26 PM, Felix Kuehling wrote:
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs w
Hi Dave, Daniel,
More new stuff for 6.3.
The following changes since commit f6e856e72ce51df1e0fe67aecb5f256fbd4190a6:
drm/amdgpu: update ta_secureDisplay_if.h to v27.00.00.08 (2023-01-05 11:43:46
-0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
Reviewed-by: Xiaogang Chen
Regards
Xiaogang
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
This is needed to correctly handle BOs imported into the GEM API, which
would otherwise get added twice to the same VM.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c |
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying
On 12/7/2022 4:08 PM, Dmitry Baryshkov wrote:
Add the platform data for sdm845 platform.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_mdss.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_mdss.
Hi Richard,
On Fri, Jan 13, 2023 at 04:24:23PM -0500, Richard Acayan wrote:
> On Fri, Jan 13, 2023 at 05:34:55PM +0100, Sam Ravnborg wrote:
> > Hi Richard/Daniel.
> Not sure if you saw the original commit that I linked.
>
> This patch was written in 2017 for the Pixel 3 and Pixel 3 XL
> smartphone
On 12/7/2022 6:28 AM, Dmitry Baryshkov wrote:
Several small corrections for the UBWC setup and related data.
I am assuming this series will be dropped in favor of the RFC:
https://patchwork.freedesktop.org/series/111751/
Right?
Dmitry Baryshkov (3):
drm/msm/dpu: handle UBWC 1.0 in dp
On 1/13/2023 1:16 PM, Dmitry Baryshkov wrote:
On Fri, 13 Jan 2023 at 21:47, Abhinav Kumar wrote:
On 12/7/2022 4:08 PM, Dmitry Baryshkov wrote:
According to the vendor DT, sm6115 has UBWC 1.0, not 2.0.
Can you please point me to which file you are referring to?
The internal docs I have a
Series is
Reviewed-by: Chia-I Wu
On Tue, Jan 10, 2023 at 3:14 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Rob Clark (3):
> drm/msm/gpu: Add devfreq tuning debugfs
> drm/msm/gpu: Bypass PM QoS constraint for idle clamp
> drm/msm/gpu: Add default devfreq thresholds
>
> drivers/gpu/drm/ms
On 1/13/2023 09:46, Hellstrom, Thomas wrote:
On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:
On 12/01/2023 20:40, John Harrison wrote:
On 1/12/2023 02:01, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error cap
On Fri, 13 Jan 2023 at 21:47, Abhinav Kumar wrote:
> On 12/7/2022 4:08 PM, Dmitry Baryshkov wrote:
> > According to the vendor DT, sm6115 has UBWC 1.0, not 2.0.
> >
>
> Can you please point me to which file you are referring to?
>
> The internal docs I have are still showing 2.0.
If I understood
On Fri, 13 Jan 2023 at 23:08, Rob Herring wrote:
>
> On Fri, Jan 13, 2023 at 08:33:51AM +0200, Dmitry Baryshkov wrote:
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > .../devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 3 +--
> > .../devicetree/bindings/display/msm/dsi-phy-14nm.yaml
On Fri, 13 Jan 2023 at 23:11, Rob Herring wrote:
>
> On Fri, Jan 13, 2023 at 09:26:52AM -0600, Rob Herring wrote:
> >
> > On Fri, 13 Jan 2023 10:37:10 +0200, Dmitry Baryshkov wrote:
> > > Convert the mdp5.txt into the yaml format. Changes to the existing (txt)
> > > schema:
> > > - MSM8996 has a
Quoting Dave Stevenson (2023-01-13 08:27:29)
> Hi Stephen
>
> On Fri, 6 Jan 2023 at 03:01, Stephen Boyd wrote:
> >
> > The unprepare sequence has started to fail after moving to panel bridge
> > code in the msm drm driver (commit 007ac0262b0d ("drm/msm/dsi: switch to
> > DRM_PANEL_BRIDGE")). You'l
On Fri, 13 Jan 2023 at 17:26, Rob Herring wrote:
>
>
> On Fri, 13 Jan 2023 10:37:10 +0200, Dmitry Baryshkov wrote:
> > Convert the mdp5.txt into the yaml format. Changes to the existing (txt)
> > schema:
> > - MSM8996 has additional "iommu" clock, define it separately
> > - Add new properties u
On Fri, Jan 13, 2023 at 09:26:52AM -0600, Rob Herring wrote:
>
> On Fri, 13 Jan 2023 10:37:10 +0200, Dmitry Baryshkov wrote:
> > Convert the mdp5.txt into the yaml format. Changes to the existing (txt)
> > schema:
> > - MSM8996 has additional "iommu" clock, define it separately
> > - Add new pr
On Fri, Jan 13, 2023 at 08:33:51AM +0200, Dmitry Baryshkov wrote:
> Signed-off-by: Dmitry Baryshkov
> ---
> .../devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 3 +--
> .../devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 3 +--
> .../devicetree/bindings/display/msm/dsi-p
Quoting Sam Ravnborg (2023-01-13 06:52:09)
> Hi Stephen,
> On Tue, Jan 10, 2023 at 11:29:41AM -0800, Stephen Boyd wrote:
> > Quoting Sam Ravnborg (2023-01-07 12:28:41)
> >
> > >
> > > For this case we could ask ourself if the display needs to enter sleep
> > > mode right before we disable the regul
On 1/12/23 23:36, Arun R Murthy wrote:
> DP2.0 E11 defines a new register to facilitate SDP error detection by a
> 128B/132B capable DPRX device.
>
> Signed-off-by: Arun R Murthy
> ---
> include/drm/display/drm_dp.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/drm/disp
On 12/7/2022 4:08 PM, Dmitry Baryshkov wrote:
Add platform data for sc8180xp based on sdmshrike-sde.dtsi.
Signed-off-by: Dmitry Baryshkov
This matches up the docs I have, hence,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_mdss.c | 8 +++-
1 file changed, 7 insertions(
Reviewed-by: Xiaogang Chen
Regards
Xiaogang
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
When restoring after an eviction, use amdgpu_vm_handle_moved to update
BO VA mappings in KFD VMs that are not managed through the KFD API. This
should allow using the render node API to create more flexibl
On 12/7/2022 4:08 PM, Dmitry Baryshkov wrote:
According to the vendor DT, sm6115 has UBWC 1.0, not 2.0.
Can you please point me to which file you are referring to?
The internal docs I have are still showing 2.0.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 2 +-
On 1/13/2023 13:28, Lyude Paul wrote:
On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:
On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
Cc: intel-gfx, drm maintainers
Please have the courtesy of Cc'ing us for changes impacting us, and
maybe try to involve us earlier instead
On 1/13/23 02:52, John Paul Adrian Glaubitz wrote:
> Hi Geert!
>
> On 1/13/23 09:26, Geert Uytterhoeven wrote:
>> Indeed. The main issue is not the lack of people sending patches and
>> fixes, but those patches never being applied by the maintainers.
>> Perhaps someone is willing to stand up to t
Hi Rob!
On 1/13/23 20:11, Rob Landley wrote:
I actually would be willing to do it but I'm a bit hesitant as I'm not 100%
sure my skills are sufficient. Maybe if someone can assist me?
My skills aren't sufficient and I dunno how much time I have, but I can
certainly assist. I test sh4 regularly
Reviewed-by: Simon Ser
__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected. ISTM this overly harsh; it doesn't
distinguish between "alternate/opposite" state, and truly
"insane/corrupted".
The "opposite" (but well-formed) state is a milder mis-initialization
problem, and some less
The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn.
Its one-time purpose was to expose a wider interface to the internal
caller: dynamic_debug_init(), to allow communicating each module's
offset in the builtin _ddebug[] table.
That purpose was obs
The dyndbg-to-trace feature is WIP, and not in mainline, so the
presence of the interface to use/test it is unhelpful/confusing.
So define DYNDBG_CLASSMAP_PARAM_T() as DYNDBG_CLASSMAP_PARAM() or
blank, depending upon ifdef DYDBG_TRACE, and update 4 params
controlling the T-flag to use it.
Signed-
lib/test_dynamic_debug.c is used to build 2 modules:
test_dynamic_debug.ko and test_dynamic_debug_submod.ko
Define DEBUG only in the main module, not in the submod. Its purpose
is to insure that prdbgs are enabled by default, so that a modprobe
without params actually logs something, showing that
Original name was a punt; but the macro is maybe general enough to put
in the API later. Rename and improve the macro towards that end.
Also tweak internal name constructed in the macro, to add a '_'
between the name components. This changes the .i file only.
no functional change.
Signed-off-b
CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; drm subsystem
modules, which depend upon drm.ko and use the drm.debug API, do not
get enabled when __drm_debug is set by `modprobe drm debug=0x1f`.
With =N, __drm_debug is checked before logging the msg, so the
end-of-modprobe debug=$init affected a
ARRAY_SIZE works here, since array decl is complete.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab7f6e 100644
--- a/incl
ddebug_apply_class_bitmap() does not alter its 2 bitmap args, make
this guarantee in the interface.
NOTE: the bitmap is also available in the dcp arg, but the 2 vars
serve a 2nd purpose; the CLASS_TYPE callers use them to translate
levels into their underlying disjoint representation.
Signed-off-
DECLARE_DYNDBG_CLASSMAP's job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need t
patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.
changes here:
0- Add William Swanson's public domain map macro:
https://github.com/swansontec/map-macro/blob/master/map.h
this makes 1 possible.
1- classnames were formerly specified a
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.
Change function's 1st arg-type, by derefing in the caller.
The fn doesnt need any other fields in the old type.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynami
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the m
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE, lets differentiate
them according to their separate jobs.
Dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
. authori
currently, for verbose=3, this is logged:
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_C
ddebug_apply_class_bitmap() currently applies the class settings to
all modules, by calling ddebug_exec_queries(query, NULL), where NULL
is wildcard ("*" does the same). Make it more selective, by adding
query_module param, and passing it into ddebug_exec_queries, instead
of the NULL.
This allows
Split param_set_dyndbg_classes() to interface-preserving wrapper &
inner function with an additional param: mod_name, which is passed
into ddebug_apply_class_bitmap() to allow adjusting a single module's
prdbgs. Wrapper passes NULL, preserving current behavior for now.
no functional change.
Sign
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly mu
Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined. Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:
[ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[ 15.293189] dyndbg: 32 debug prints in mod
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/t
Hi everyone,
DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in drivers
It is due to a chicken-egg problem loading modules; on `modprobe
i915`, drm is loaded 1st, and drm/parameters/debug is set. When
drm_debug_enabled() tested it at runtime, things just worked.
But with DRM_USE_DYN
On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
> >
> > Cc: intel-gfx, drm maintainers
> >
> > Please have the courtesy of Cc'ing us for changes impacting us, and
> > maybe try to involve us earlier instead of surprising us li
On Wed, 11 Jan 2023 20:37:10 +0800, Allen-KH Cheng wrote:
> The mt8186-disp-ccorr is not fully compatible with the mt8183-disp-ccorr
> implementation. It causes a crash when system resumes if it binds to the
> device.
>
> We should use mt8192-disp-ccorr as fallback of mt8186-disp-ccorr.
>
> Fix
On Wed, 11 Jan 2023 20:37:04 +0800, Allen-KH Cheng wrote:
> The mt8186-spmi is used as compatible with mt8195-spmi on the MT8186,
> document this situation.
>
> Signed-off-by: Allen-KH Cheng
> ---
> .../devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml | 11 ---
> 1 file changed, 8 ins
On 1/11/2023 2:21 PM, Marijn Suijten wrote:
On 2023-01-11 17:11:03, Dmitry Baryshkov wrote:
On 11/01/2023 10:44, Marijn Suijten wrote:
On 2023-01-09 12:32:18, Abhinav Kumar wrote:
On 12/7/2022 4:08 PM, Dmitry Baryshkov wrote:
+struct msm_mdss_data {
+ u32 ubwc_version;
+ u32 ubwc_
On Wed, Jan 11, 2023 at 09:20:40PM +0530, Deepak R Varma wrote:
> This patch series proposes to replace a combination of
> DEFINE_SIMPLE_ATTRIBUTE() +
> debugfs_create_file() by a combination of DEFINE_DEBUGFS_ATTRIBUTE() +
> debugfs_create_file_unsafe(). The change reduced overhead in terms of ma
On Fri, Jan 13, 2023 at 11:29:57AM -0700, jim.cro...@gmail.com wrote:
> On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter wrote:
> >
> > On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > > Hi everyone,
> > >
> > > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> > >
> > > Regression is
On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter wrote:
>
> On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > Hi everyone,
> >
> > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> >
> > Regression is due to a chicken-egg problem loading modules; on
> > `modprobe i915`, drm is loaded 1
On Tue, Jan 10, 2023 at 05:48:45PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-12-12 at 15:15 -0800, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence u
On 02-10-22, 08:45, Michael Trimarchi wrote:
> The function is used to avoid to enable clock on the hardware
> if the mode requested is invalid
>
> Signed-off-by: Michael Trimarchi
> ---
> .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 19 +++
> 1 file changed, 19 insertions(+)
On 1/13/23 14:06, Simon Ser wrote:
Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.
I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check in framebuff
On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:
>
> On 12/01/2023 20:40, John Harrison wrote:
> > On 1/12/2023 02:01, Tvrtko Ursulin wrote:
> > > On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
> > > > From: John Harrison
> > > >
> > > > There was a report of error captures occurr
On Thu, Jan 12, 2023 at 02:31:45PM -0800, Prashant Malani wrote:
> On Thu, Jan 12, 2023 at 5:32 AM Sakari Ailus
> wrote:
> > On Thu, Jan 12, 2023 at 12:20:56PM +0800, Pin-yen Lin wrote:
> > > From: Prashant Malani
...
> > > + /*
> > > + * Some drivers may register devic
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 6b31ffe9c8b9947d6d3552d6e10752fd96d0f80f Add linux-next specific
files for 20230113
Error/Warning: (recently discovered and may have been fixed)
aarch64-linux-ld: ID map text too big or
Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.
I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check in framebuffer_init()? (Not sure!)
On Friday, January 13th, 2023 at 17:59, Maíra Canal wrote:
> + /* Verify that the modifier is supported. */
> + if (r->modifier[0] && drm_drv_uses_atomic_modeset(dev) &&
> + !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
> + drm_dbg_kms(dev, "Unsupp
Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on vmwgfx's inside
helpers.
Therefore, remove the redundant framebuffer format check from the
vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_bo()
functions, letting frameb
Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on amdgpu's inside
helpers.
Therefore, remove the redundant framebuffer format check from the
amdgpu_display_gem_fb_verify_and_init() function, letting
framebuffer_check() perform the fr
This series is a follow-up of the [1] in which I introduced a check for valid
formats on drm_gem_fb_create(). During the discussion, I realized that would be
a better idea to put the check inside framebuffer_check() so that it wouldn't be
needed to hit any driver-specific code path when the check f
Currently, framebuffer_check() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
calls with invalid for
On Fri, 13 Jan 2023 16:46:37 +0100, Maxime Ripard wrote:
> Commit 07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog")
> removed the only user of the ret variable, but didn't remove the
> variable itself leading to a unused variable warning.
>
> Remove that variable.
>
>
> [...]
Applied
On Fri, Jan 13, 2023 at 11:23:44AM +0200, Heikki Krogerus wrote:
> On Thu, Jan 12, 2023 at 12:20:58PM +0800, Pin-yen Lin wrote:
...
> > + dev_err(dev, "Failed to read the data-lanes variable from %s:
> > %d\n",
> > + node->name, ret);
>
> fwnode
Hi Richard/Daniel.
On Thu, Jan 12, 2023 at 11:18:48PM -0500, Richard Acayan wrote:
> From: Daniel Mentz
>
> The MIPI DCS specification demands that brightness values are sent in
> big endian byte order. It also states that one parameter (i.e. one byte)
> shall be sent/received for 8 bit wide val
On 1/13/2023 1:23 AM, Jacek Lawrynowicz wrote:
Hi,
On 12.01.2023 18:34, Jeffrey Hugo wrote:
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
VPU stands for Versatile Processing Unit and it's a CPU-integrated
inference accelerator for Computer Vision and Deep Learning
applications.
The VPU device
Hi Stephen
On Fri, 6 Jan 2023 at 03:01, Stephen Boyd wrote:
>
> The unprepare sequence has started to fail after moving to panel bridge
> code in the msm drm driver (commit 007ac0262b0d ("drm/msm/dsi: switch to
> DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs:
>
>panel-
From: Joshua Ashton
Given that we always pass dm_state into here now, this won't ever
trigger anymore.
This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebast
v3: Fix kerneldocs (kernel test robot)
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-By: Joshua
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-By: Joshua Ashton
---
drivers/gpu/drm/drm_connec
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Seba
From: Joshua Ashton
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/displa
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 Paal
From: Joshua Ashton
Replace the messy two if-else chains here that were
on the same value with a switch on the enum.
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.
Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.
Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.
v2:
- Use 0 to indicate
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
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
Review
The value is the same as DEFAULT. The HDMI_COLORIMETRY_NO_DATA
makes sense for the infopacket but it's meaningless for the
connector colorspace. or, in otherwise, just means to go with
driver default.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
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: am
This allows us to use strongly typed arguments.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-B
From: Joshua Ashton
Code in get_output_color_space depends on knowing the pixel encoding to
determine whether to pick between eg. COLOR_SPACE_SRGB or
COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paal
This will let us pass the kms_hdr.bpc_switch IGT
test.
The reason the bpc restriction was required is
historical. At one point in time we were not falling
back to a lower bpc when we didn't have enough
bandwidth for the maximum bpc reported by a display.
This meant that we couldn't enable some hig
Format the input and output CSC matrix so they
look like 3x4 matrixes. This will make parsing them
much easier and allows us to quickly spot potential
mistakes.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-devel@lists.
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: Joshua Ashton
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
1 file
Look at connector->colorimetry to determine output colorspace.
We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-dev
We use this by default but if userspace passes this explicitly
we should respect it.
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: Joshua Ashton
We need to signal mode_changed to make sure we update the output
colorspace.
v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Vill
This is useful to understand the bpc defaults and
support of a driver.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.fre
1 - 100 of 197 matches
Mail list logo
