Re: [PATCH v3 1/4] drm/sched: store the drm_device instead of the device
On Thu, Jun 06, 2024 at 03:18:14PM +0200, Christian König wrote: > Am 06.06.24 um 15:06 schrieb Pierre-Eric Pelloux-Prayer: > > When tracing is enabled, being able to identify which device is sending > > events is useful; for this the next commit will extend events to include > > drm_device::primary::index. > > That sounds like a rather bad idea since the primary index is really > just an arbitrary number and not defined for all devices. > > Why not use the device name instead? This way you don't need this change > in the first place. FWIW dev_name() is what I added to all i915 display tracepoints. -- Ville Syrjälä Intel
Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Thu, Jun 06, 2024 at 10:21:07AM +0300, Jani Nikula wrote:
> On Wed, 05 Jun 2024, Chris Bainbridge wrote:
> > On Tue, Jun 04, 2024 at 10:02:29AM +0800, kernel test robot wrote:
> >> Hi Mario,
> >>
> >> kernel test robot noticed the following build errors:
> >>
> >> [auto build test ERROR on drm-misc/drm-misc-next]
> >> [also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
> >> drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
> >> linus/master v6.10-rc2 next-20240603]
> >> [If your patch is applied to the wrong git tree, kindly drop us a note.
> >> And when submitting patch, we suggest to use '--base' as documented in
> >> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >>
> >> url:
> >> https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-client-Detect-when-ACPI-lid-is-closed-during-initialization/20240529-050440
> >> base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> >> patch link:
> >> https://lore.kernel.org/r/20240528210319.1242-1-mario.limonciello%40amd.com
> >> patch subject: [PATCH v2] drm/client: Detect when ACPI lid is closed
> >> during initialization
> >> config: i386-randconfig-053-20240604
> >> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/config)
> >> compiler: gcc-9 (Ubuntu 9.5.0-4ubuntu2) 9.5.0
> >> reproduce (this is a W=1 build):
> >> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/reproduce)
> >>
> >> If you fix the issue in a separate patch/commit (i.e. not just a new
> >> version of
> >> the same patch/commit), kindly add following tags
> >> | Reported-by: kernel test robot
> >> | Closes:
> >> https://lore.kernel.org/oe-kbuild-all/202406040928.eu1griwv-...@intel.com/
> >>
> >> All errors (new ones prefixed by >>):
> >>
> >>ld: drivers/gpu/drm/drm_client_modeset.o: in function
> >> `drm_client_match_edp_lid':
> >> >> drivers/gpu/drm/drm_client_modeset.c:281:(.text+0x221b): undefined
> >> >> reference to `acpi_lid_open'
> >>
> >>
> >> vim +281 drivers/gpu/drm/drm_client_modeset.c
> >>
> >>260
> >>261 static void drm_client_match_edp_lid(struct drm_device *dev,
> >>262 struct drm_connector
> >> **connectors,
> >>263 unsigned int
> >> connector_count,
> >>264 bool *enabled)
> >>265 {
> >>266 int i;
> >>267
> >>268 for (i = 0; i < connector_count; i++) {
> >>269 struct drm_connector *connector = connectors[i];
> >>270
> >>271 switch (connector->connector_type) {
> >>272 case DRM_MODE_CONNECTOR_LVDS:
> >>273 case DRM_MODE_CONNECTOR_eDP:
> >>274 if (!enabled[i])
> >>275 continue;
> >>276 break;
> >>277 default:
> >>278 continue;
> >>279 }
> >>280
> >> > 281 if (!acpi_lid_open()) {
> >>282 drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid
> >> is closed, disabling\n",
> >>283 connector->base.id,
> >> connector->name);
> >>284 enabled[i] = false;
> >>285 }
> >>286 }
> >>287 }
> >>288
> >>
> >> --
> >> 0-DAY CI Kernel Test Service
> >> https://github.com/intel/lkp-tests/wiki
> >
> > The failed config has CONFIG_ACPI_BUTTON=m. The build failure can be
> > fixed with:
> >
> > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > b/drivers/gpu/drm/drm_client_modeset.c
> > index b76438c31761..0271e66f44f8 100644
> > --- a/drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -271,11 +271,13 @@ static void drm_client_match_edp_lid(struct
> > drm_device *dev,
> > if (connector->connector_type != DRM_MODE_CONNECTOR_eDP ||
> > !enabled[i])
> > continue;
> >
> > +#if defined(CONFIG_ACPI_BUTTON)
> > if (!acpi_lid_open()) {
> > drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed,
> > disabling\n",
> > connector->base.id, connector->name);
> > enabled[i] = false;
> > }
> > +#endif
> > }
> > }
>
> No. This is because
>
> CONFIG_DRM=y
> CONFIG_ACPI_BUTTON=m
>
> The pedantically correct fix is probably having DRM
>
> depends on ACPI_BUTTON || ACPI_BUTTON=n
>
> but seeing how i915 and xe just
>
> select ACPI_BUTTON if ACPI
Huh. We should nuke that as we haven't used this lid stuff in ages.
--
Ville Syrjälä
Intel
Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Wed, May 29, 2024 at 09:45:55AM -0500, Mario Limonciello wrote:
> On 5/29/2024 09:14, Ville Syrjälä wrote:
> > On Tue, May 28, 2024 at 04:03:19PM -0500, Mario Limonciello wrote:
> >> If the lid on a laptop is closed when eDP connectors are populated
> >> then it remains enabled when the initial framebuffer configuration
> >> is built.
> >>
> >> When creating the initial framebuffer configuration detect the ACPI
> >> lid status and if it's closed disable any eDP connectors.
> >>
> >> Reported-by: Chris Bainbridge
> >> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
> >> Signed-off-by: Mario Limonciello
> >> ---
> >> Cc: hughsi...@gmail.com
> >> v1->v2:
> >> * Match LVDS as well
> >> ---
> >> drivers/gpu/drm/drm_client_modeset.c | 30
> >> 1 file changed, 30 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> >> b/drivers/gpu/drm/drm_client_modeset.c
> >> index 31af5cf37a09..0b0411086e76 100644
> >> --- a/drivers/gpu/drm/drm_client_modeset.c
> >> +++ b/drivers/gpu/drm/drm_client_modeset.c
> >> @@ -8,6 +8,7 @@
> >>*/
> >>
> >> #include "drm/drm_modeset_lock.h"
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct
> >> drm_connector **connectors,
> >>enabled[i] = drm_connector_enabled(connectors[i], false);
> >> }
> >>
> >> +static void drm_client_match_edp_lid(struct drm_device *dev,
> >> + struct drm_connector **connectors,
> >> + unsigned int connector_count,
> >> + bool *enabled)
> >> +{
> >> + int i;
> >> +
> >> + for (i = 0; i < connector_count; i++) {
> >> + struct drm_connector *connector = connectors[i];
> >> +
> >> + switch (connector->connector_type) {
> >> + case DRM_MODE_CONNECTOR_LVDS:
> >> + case DRM_MODE_CONNECTOR_eDP:
> >> + if (!enabled[i])
> >> + continue;
> >> + break;
> >> + default:
> >> + continue;
> >> + }
> >> +
> >> + if (!acpi_lid_open()) {
> >> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed,
> >> disabling\n",
> >> + connector->base.id, connector->name);
> >> + enabled[i] = false;
> >> + }
> >> + }
> >> +}
> >
> > If you don't hook into some lid notify event how is one supposed to get
> > the display back to life after opening the lid?
>
> I guess in my mind it's a tangential to the "initial modeset". The DRM
> master can issue a modeset to enable the combination as desired.
This code is run whenever there's a hotplug/etc. Not sure why you're
only thinking about the initial modeset.
>
> When I tested I did confirm that with mutter such an event is received
> and it does the modeset to enable the eDP when lid is opened.
This code isn't relevant when you have a userspace drm master
calling the shots.
>
> Let me ask this - what happens if no DRM master running and you hotplug
> a DP cable? Does a "new" clone configuration get done?
Yes, this code reprobes the displays and comes up with a new
config to suit the new situation.
The other potential issue here is whether acpi_lid_open() is actually
trustworthy. Some kms drivers have/had some lid handling in their own
code, and I'm pretty sure those have often needed quirks/modparams
to actually do sensible things on certain machines.
FWIW I ripped out all the lid crap from i915 long ago since it was
half backed, mostly broken, and ugly, and I'm not looking to add it
back there. But I do think handling that in drm_client does seem
somewhat sane, as that should more or less match what userspace
clients would do. Just a question of how bad the quirk situation
will get...
Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
someone needs this to work on non-ACPI system they get to figure out
how to abstract it better. acpi_lid_open() does seem to return != 0
when ACPI is not supported, so at least it would err on the side
of enabling everything.
--
Ville Syrjälä
Intel
Re: [PATCH 4/9] drm/i915: Introduce fb->min_alignment
On Wed, May 29, 2024 at 12:37:30AM +0300, Imre Deak wrote:
> On Tue, May 28, 2024 at 10:38:06PM +0300, Ville Syrjälä wrote:
> > On Tue, May 28, 2024 at 02:27:52PM +0300, Imre Deak wrote:
> > > On Mon, May 13, 2024 at 08:59:37PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Different planes could have different alignment requirements
> > > > even for the same format/modifier. Collect the alignment
> > > > requirements across all planes capable of scanning out the
> > > > fb such that the alignment used when pinning the normal ggtt
> > > > view is satisfactory to all those planes.
> > > >
> > > > When pinning per-plane views we only have to satisfy the
> > > > alignment requirements of the specific plane.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > .../drm/i915/display/intel_display_types.h| 2 ++
> > > > drivers/gpu/drm/i915/display/intel_fb.c | 23
> > > > drivers/gpu/drm/i915/display/intel_fb_pin.c | 27 +--
> > > > drivers/gpu/drm/i915/display/intel_fbdev.c| 18 +
> > > > 4 files changed, 51 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > index 40d6e5f4c350..58bb65832adf 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > @@ -145,6 +145,8 @@ struct intel_framebuffer {
> > > > };
> > > >
> > > > struct i915_address_space *dpt_vm;
> > > > +
> > > > + unsigned int min_alignment;
> > > > };
> > > >
> > > > enum intel_hotplug_state {
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > > > b/drivers/gpu/drm/i915/display/intel_fb.c
> > > > index 3f3a9cd534f4..c5bae05cbbc3 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > > > @@ -10,6 +10,7 @@
> > > > #include
> > > >
> > > > #include "i915_drv.h"
> > > > +#include "intel_atomic_plane.h"
> > > > #include "intel_display.h"
> > > > #include "intel_display_types.h"
> > > > #include "intel_dpt.h"
> > > > @@ -1616,6 +1617,26 @@ bool intel_fb_supports_90_270_rotation(const
> > > > struct intel_framebuffer *fb)
> > > >fb->base.modifier == I915_FORMAT_MOD_Yf_TILED;
> > > > }
> > > >
> > > > +static unsigned int intel_fb_min_alignment(const struct
> > > > drm_framebuffer *fb)
> > > > +{
> > > > + struct drm_i915_private *i915 = to_i915(fb->dev);
> > > > + struct intel_plane *plane;
> > > > + unsigned int min_alignment = 0;
> > > > +
> > > > + for_each_intel_plane(>drm, plane) {
> > > > + if (!drm_plane_has_format(>base,
> > > > fb->format->format, fb->modifier))
> > > > + continue;
> > > > +
> > > > + if (intel_plane_needs_physical(plane))
> > > > + continue;
> > > > +
> > > > + min_alignment = max(min_alignment,
> > > > + plane->min_alignment(plane, fb, 0));
> > > > + }
> > > > +
> > > > + return min_alignment;
> > > > +}
> > > > +
> > > > int intel_fill_fb_info(struct drm_i915_private *i915, struct
> > > > intel_framebuffer *fb)
> > > > {
> > > > struct drm_i915_gem_object *obj = intel_fb_obj(>base);
> > > > @@ -1698,6 +1719,8 @@ int intel_fill_fb_info(struct drm_i915_private
> > > > *i915, struct intel_framebuffer *
> > > > return -EINVAL;
> > > > }
> > > >
> > > > + fb->min_alignment = intel_fb_min_alignment(>base);
> > > > +
> > > > return 0;
> > > > }
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > > > b/dri
Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Tue, May 28, 2024 at 04:03:19PM -0500, Mario Limonciello wrote:
> If the lid on a laptop is closed when eDP connectors are populated
> then it remains enabled when the initial framebuffer configuration
> is built.
>
> When creating the initial framebuffer configuration detect the ACPI
> lid status and if it's closed disable any eDP connectors.
>
> Reported-by: Chris Bainbridge
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
> Signed-off-by: Mario Limonciello
> ---
> Cc: hughsi...@gmail.com
> v1->v2:
> * Match LVDS as well
> ---
> drivers/gpu/drm/drm_client_modeset.c | 30
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index 31af5cf37a09..0b0411086e76 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -8,6 +8,7 @@
> */
>
> #include "drm/drm_modeset_lock.h"
> +#include
> #include
> #include
> #include
> @@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct
> drm_connector **connectors,
> enabled[i] = drm_connector_enabled(connectors[i], false);
> }
>
> +static void drm_client_match_edp_lid(struct drm_device *dev,
> + struct drm_connector **connectors,
> + unsigned int connector_count,
> + bool *enabled)
> +{
> + int i;
> +
> + for (i = 0; i < connector_count; i++) {
> + struct drm_connector *connector = connectors[i];
> +
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_LVDS:
> + case DRM_MODE_CONNECTOR_eDP:
> + if (!enabled[i])
> + continue;
> + break;
> + default:
> + continue;
> + }
> +
> + if (!acpi_lid_open()) {
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed,
> disabling\n",
> + connector->base.id, connector->name);
> + enabled[i] = false;
> + }
> + }
> +}
If you don't hook into some lid notify event how is one supposed to get
the display back to life after opening the lid?
> +
> static bool drm_client_target_cloned(struct drm_device *dev,
>struct drm_connector **connectors,
>unsigned int connector_count,
> @@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev
> *client, unsigned int width,
> memset(crtcs, 0, connector_count * sizeof(*crtcs));
> memset(offsets, 0, connector_count * sizeof(*offsets));
>
> + drm_client_match_edp_lid(dev, connectors, connector_count,
> enabled);
> if (!drm_client_target_cloned(dev, connectors, connector_count,
> modes,
> offsets, enabled, width, height)
> &&
> !drm_client_target_preferred(dev, connectors,
> connector_count, modes,
> --
> 2.43.0
--
Ville Syrjälä
Intel
Re: [PATCH 07/21] drm/sti: Allow build with COMPILE_TEST=y
On Mon, May 27, 2024 at 05:29:09PM +0200, Alain Volmat wrote: > Hi Ville, > > thank you for your patch. > > On Mon, Apr 08, 2024 at 08:04:12PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Allow sti to be built with COMPILE_TEST=y for greater > > coverage. Builds fine on x86/x86_64 at least. > > > > Cc: Alain Volmat > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/sti/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig > > index 3c7a5feff8de..75c301aadcbc 100644 > > --- a/drivers/gpu/drm/sti/Kconfig > > +++ b/drivers/gpu/drm/sti/Kconfig > > @@ -1,7 +1,7 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > config DRM_STI > > tristate "DRM Support for STMicroelectronics SoC stiH4xx Series" > > - depends on OF && DRM && ARCH_STI > > + depends on OF && DRM && (ARCH_STI || COMPILE_TEST) > > select RESET_CONTROLLER > > select DRM_KMS_HELPER > > select DRM_GEM_DMA_HELPER > > -- > > 2.43.2 > > > > Acked-by: Alain Volmat Thanks. Pushed both sti patches to drm-misc-next. -- Ville Syrjälä Intel
Re: [PATCH 4/9] drm/i915: Introduce fb->min_alignment
On Tue, May 28, 2024 at 02:27:52PM +0300, Imre Deak wrote:
> On Mon, May 13, 2024 at 08:59:37PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Different planes could have different alignment requirements
> > even for the same format/modifier. Collect the alignment
> > requirements across all planes capable of scanning out the
> > fb such that the alignment used when pinning the normal ggtt
> > view is satisfactory to all those planes.
> >
> > When pinning per-plane views we only have to satisfy the
> > alignment requirements of the specific plane.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../drm/i915/display/intel_display_types.h| 2 ++
> > drivers/gpu/drm/i915/display/intel_fb.c | 23
> > drivers/gpu/drm/i915/display/intel_fb_pin.c | 27 +--
> > drivers/gpu/drm/i915/display/intel_fbdev.c| 18 +
> > 4 files changed, 51 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 40d6e5f4c350..58bb65832adf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -145,6 +145,8 @@ struct intel_framebuffer {
> > };
> >
> > struct i915_address_space *dpt_vm;
> > +
> > + unsigned int min_alignment;
> > };
> >
> > enum intel_hotplug_state {
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index 3f3a9cd534f4..c5bae05cbbc3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -10,6 +10,7 @@
> > #include
> >
> > #include "i915_drv.h"
> > +#include "intel_atomic_plane.h"
> > #include "intel_display.h"
> > #include "intel_display_types.h"
> > #include "intel_dpt.h"
> > @@ -1616,6 +1617,26 @@ bool intel_fb_supports_90_270_rotation(const struct
> > intel_framebuffer *fb)
> >fb->base.modifier == I915_FORMAT_MOD_Yf_TILED;
> > }
> >
> > +static unsigned int intel_fb_min_alignment(const struct drm_framebuffer
> > *fb)
> > +{
> > + struct drm_i915_private *i915 = to_i915(fb->dev);
> > + struct intel_plane *plane;
> > + unsigned int min_alignment = 0;
> > +
> > + for_each_intel_plane(>drm, plane) {
> > + if (!drm_plane_has_format(>base, fb->format->format,
> > fb->modifier))
> > + continue;
> > +
> > + if (intel_plane_needs_physical(plane))
> > + continue;
> > +
> > + min_alignment = max(min_alignment,
> > + plane->min_alignment(plane, fb, 0));
> > + }
> > +
> > + return min_alignment;
> > +}
> > +
> > int intel_fill_fb_info(struct drm_i915_private *i915, struct
> > intel_framebuffer *fb)
> > {
> > struct drm_i915_gem_object *obj = intel_fb_obj(>base);
> > @@ -1698,6 +1719,8 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
> > struct intel_framebuffer *
> > return -EINVAL;
> > }
> >
> > + fb->min_alignment = intel_fb_min_alignment(>base);
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > index 9b0f1ea41b70..1ae02de906f5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > @@ -230,13 +230,36 @@ void intel_fb_unpin_vma(struct i915_vma *vma,
> > unsigned long flags)
> > i915_vma_put(vma);
> > }
> >
> > +static bool gtt_view_is_per_plane(const struct intel_plane_state
> > *plane_state)
> > +{
> > + const struct intel_framebuffer *fb =
> > to_intel_framebuffer(plane_state->hw.fb);
> > +
> > + if (plane_state->view.gtt.type == I915_GTT_VIEW_REMAPPED &&
> > + intel_fb_needs_pot_stride_remap(fb))
> > + return false;
>
> The above view is created only once for the FB, I suppose this is how
> you differentiate it from views created each time due to a stride
> limit (based on intel_plane_needs_remap()).
>
> > +
> > + return plane_state->view.gtt.type != I915_GTT_VIEW_NORMAL;
>
> So the rotated and
Re: [PATCH 8/9] drm/i915: Update plane alignment requirements for TGL+
On Tue, May 28, 2024 at 04:22:59PM +0300, Imre Deak wrote:
> On Mon, May 13, 2024 at 08:59:41PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we still use the SKL+ PLANE_SURF alignment even
> > for TGL+ even though the hardware no longer needs it.
> > Introduce a separate tgl_plane_min_alignment() and update
> > it to more accurately reflect the hardware requirements.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../drm/i915/display/skl_universal_plane.c| 103 ++
> > 1 file changed, 55 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 1ecd7c691317..ca7fc9fae990 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -502,75 +502,79 @@ skl_plane_max_stride(struct intel_plane *plane,
> > max_pixels, max_bytes);
> > }
> >
> > -static unsigned int skl_plane_min_alignment(struct intel_plane *plane,
> > - const struct drm_framebuffer *fb,
> > - int color_plane)
> > +static u32 tgl_plane_min_alignment(struct intel_plane *plane,
> > + const struct drm_framebuffer *fb,
> > + int color_plane)
> > {
> > - struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > -
> > - if (intel_fb_uses_dpt(fb)) {
> > - /* AUX_DIST needs only 4K alignment */
> > - if (intel_fb_is_ccs_aux_plane(fb, color_plane))
> > - return 512 * 4096;
> > -
> > - /*
> > -* FIXME ADL sees GGTT/DMAR faults with async
> > -* flips unless we align to 16k at least.
> > -* Figure out what's going on here...
> > -*/
> > - if (IS_ALDERLAKE_P(dev_priv) &&
> > - !intel_fb_is_ccs_modifier(fb->modifier) &&
> > - HAS_ASYNC_FLIPS(dev_priv))
> > - return 512 * 16 * 1024;
> > -
> > - return 512 * 4096;
> > - }
> > + struct drm_i915_private *i915 = to_i915(plane->base.dev);
> > + /* PLANE_SURF GGTT -> DPT alignment */
> > + int mult = intel_fb_uses_dpt(fb) ? 512 : 1;
> >
> > /* AUX_DIST needs only 4K alignment */
> > if (intel_fb_is_ccs_aux_plane(fb, color_plane))
> > - return 4096;
> > + return mult * 4 * 1024;
> >
> > if (is_semiplanar_uv_plane(fb, color_plane)) {
> > /*
> > * TODO: cross-check wrt. the bspec stride in bytes * 64 bytes
> > * alignment for linear UV planes on all platforms.
> > */
> > - if (DISPLAY_VER(dev_priv) >= 12) {
> > - if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> > - return 256 * 1024;
> > -
> > - return intel_tile_row_size(fb, color_plane);
> > - }
> > -
> > - return 4096;
> > - }
> > -
> > - drm_WARN_ON(_priv->drm, color_plane != 0);
> > -
> > - switch (fb->modifier) {
> > - case DRM_FORMAT_MOD_LINEAR:
> > - return 256 * 1024;
> > - case I915_FORMAT_MOD_X_TILED:
> > - if (HAS_ASYNC_FLIPS(dev_priv))
> > + if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> > return 256 * 1024;
> > - return 0;
> > +
> > + return intel_tile_row_size(fb, color_plane);
> > + }
> > +
> > + switch (fb->modifier) {
> > + case DRM_FORMAT_MOD_LINEAR:
> > + case I915_FORMAT_MOD_X_TILED:
> > + case I915_FORMAT_MOD_Y_TILED:
> > + case I915_FORMAT_MOD_4_TILED:
> > + /*
> > +* FIXME ADL sees GGTT/DMAR faults with async
> > +* flips unless we align to 16k at least.
> > +* Figure out what's going on here...
> > +*/
> > + if (IS_ALDERLAKE_P(i915) && HAS_ASYNC_FLIPS(i915))
>
> On ADL HAS_ASYNC_FLIPS() is always true, otherwise looks ok:
I've been using HAS_ASYNC_FLIPS() to just flag the async flip
specific restrictions. So mainly an aide memoire, but it can
technically be used to also test with less alignment
by just neutering HAS_ASYNC_FLIPS(), without having go trawl
the specs for the specific number again.
Though I'm not
Re: [PATCH 3/4] drm/imx: fix -Wformat-truncation warning in imx_ldb_probe()
On Thu, May 23, 2024 at 06:51:08PM +0300, Jani Nikula wrote:
> Enabling -Wformat-truncation yields the following warning:
>
> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c: In function ‘imx_ldb_probe’:
> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c:658:57: error: ‘_sel’ directive output
> may be truncated writing 4 bytes into a region of size between 3 and 13
> [-Werror=format-truncation=]
> 658 | snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> | ^~~~
> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c:658:17: note: ‘snprintf’ output
> between 8 and 18 bytes into a destination of size 16
> 658 | snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> | ^
If only the compiler could count to three...
>
> Silence the warning by checking the snprintf() return value.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Philipp Zabel
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: dri-devel@lists.freedesktop.org
> Cc: i...@lists.linux.dev
> ---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> index 71d70194fcbd..46f779fe60ee 100644
> --- a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> +++ b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> @@ -654,8 +654,12 @@ static int imx_ldb_probe(struct platform_device *pdev)
>*/
> for (i = 0; i < 4; i++) {
> char clkname[16];
> + int len;
> +
> + len = snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> + if (len >= sizeof(clkname))
> + dev_err(dev, "clkname truncated\n");
>
> - snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> imx_ldb->clk_sel[i] = devm_clk_get(imx_ldb->dev, clkname);
> if (IS_ERR(imx_ldb->clk_sel[i])) {
> ret = PTR_ERR(imx_ldb->clk_sel[i]);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH] drm/probe-helper: Call drm_mode_validate_ycbcr420() before connector->mode_valid()
On Tue, May 21, 2024 at 02:09:19PM +0200, Daniel Vetter wrote:
> On Thu, May 16, 2024 at 08:33:24PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier for drivers by filtering out unwanted YCbCr 4:2:0
> > only modes prior to calling the connector->mode_valid() hook.
> > Currently drivers will still see YCbCr 4:2:0 only modes in said
> > hook, which will likely come as a suprise when the driver has
> > declared no support for such modes (via setting
> > connector->ycbcr_420_allowed to false).
> >
> > Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10992
> > Signed-off-by: Ville Syrjälä
>
> Sounds reasonable.
>
> Reviewed-by: Daniel Vetter
Thanks. Pushed to drm-misc-next.
>
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 4f75a1cfd820..249c8c2cb319 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -474,6 +474,10 @@ static int __drm_helper_update_and_validate(struct
> > drm_connector *connector,
> > if (mode->status != MODE_OK)
> > continue;
> >
> > + mode->status = drm_mode_validate_ycbcr420(mode, connector);
> > + if (mode->status != MODE_OK)
> > + continue;
> > +
> > ret = drm_mode_validate_pipeline(mode, connector, ctx,
> > >status);
> > if (ret) {
> > @@ -486,10 +490,6 @@ static int __drm_helper_update_and_validate(struct
> > drm_connector *connector,
> > else
> > return -EDEADLK;
> > }
> > -
> > - if (mode->status != MODE_OK)
> > - continue;
> > - mode->status = drm_mode_validate_ycbcr420(mode, connector);
> > }
> >
> > return 0;
> > --
> > 2.44.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
Re: [PATCH] drm: use "0" instead of "" for deprecated driver date
On Fri, May 10, 2024 at 08:33:59PM +0300, Ville Syrjälä wrote:
> On Fri, May 10, 2024 at 12:09:51PM +0300, Jani Nikula wrote:
> > libdrm does not like the empty string for driver date. Use "0" instead,
> > which has been used by virtio previously.
> >
> > Reported-by: Steven Price
> > Closes:
> > https://lore.kernel.org/r/9d0cff47-308e-4b11-a9f3-4157dc26b...@arm.com
> > Fixes: 7fb8af6798e8 ("drm: deprecate driver date")
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 89feb7306e47..51f39912866f 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -530,9 +530,9 @@ int drm_version(struct drm_device *dev, void *data,
> > err = drm_copy_field(version->name, >name_len,
> > dev->driver->name);
> >
> > - /* Driver date is deprecated. Return the empty string. */
> > + /* Driver date is deprecated. Userspace expects a non-empty string. */
> > if (!err)
> > - err = drm_copy_field(version->date, >date_len, "");
> > + err = drm_copy_field(version->date, >date_len, "0");
>
> Does this also fix igt/core_getversion which is on fire now?
At least it fixes Xorg which currently just segfaults.
Pushed to drm-misc-next. Thanks everyone.
>
> > if (!err)
> > err = drm_copy_field(version->desc, >desc_len,
> > dev->driver->desc);
> > --
> > 2.39.2
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
Re: [PATCH] drm: use "0" instead of "" for deprecated driver date
On Fri, May 10, 2024 at 12:09:51PM +0300, Jani Nikula wrote:
> libdrm does not like the empty string for driver date. Use "0" instead,
> which has been used by virtio previously.
>
> Reported-by: Steven Price
> Closes: https://lore.kernel.org/r/9d0cff47-308e-4b11-a9f3-4157dc26b...@arm.com
> Fixes: 7fb8af6798e8 ("drm: deprecate driver date")
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 89feb7306e47..51f39912866f 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -530,9 +530,9 @@ int drm_version(struct drm_device *dev, void *data,
> err = drm_copy_field(version->name, >name_len,
> dev->driver->name);
>
> - /* Driver date is deprecated. Return the empty string. */
> + /* Driver date is deprecated. Userspace expects a non-empty string. */
> if (!err)
> - err = drm_copy_field(version->date, >date_len, "");
> + err = drm_copy_field(version->date, >date_len, "0");
Does this also fix igt/core_getversion which is on fire now?
> if (!err)
> err = drm_copy_field(version->desc, >desc_len,
> dev->driver->desc);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH 1/2] drm: Allow mode object properties to be added after a device is registered
On Wed, May 08, 2024 at 02:43:07PM -0500, Mario Limonciello wrote:
> When the colorspace property is registered on MST devices there is
> no `obj_free_cb` callback for it in drm_mode_object_add().
>
> Don't show a warning trace for __drm_mode_object_add() calls for
> DRM_MODE_OBJECT_PROPERTY.
You need to create the property ahead of time. See eg.
commit 1b9bd09630d4 ("drm/i915: Do not create a new max_bpc prop for MST
connectors")
>
> Reported-and-tested-by: Tyler Schneider
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
> Signed-off-by: Mario Limonciello
> ---
> drivers/gpu/drm/drm_mode_object.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c
> b/drivers/gpu/drm/drm_mode_object.c
> index 0e8355063eee..b077547a2db4 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct
> drm_mode_object *obj,
> {
> int ret;
>
> - WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
> + WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb &&
> obj_type != DRM_MODE_OBJECT_PROPERTY);
>
> mutex_lock(>mode_config.idr_mutex);
> ret = idr_alloc(>mode_config.object_idr, register_obj ? obj : NULL,
> --
> 2.43.0
--
Ville Syrjälä
Intel
Re: [PATCH 00/21] drm: Increase COMPILE_TEST=y coverage
On Mon, Apr 08, 2024 at 08:04:05PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > I got fed up having to build multiple architectures when > doing subsystem wide refactoring. So I decided to attack > the low hanging COMPILE_TEST=y fruit. Here are the > results. All of these drivers now build with COMPILE_TEST=y > on x86/x86_64 > > Ville Syrjälä (21): > drm/hisilicon/kirin: Include linux/io.h for readl()/writel() > drm/hisilicon/kirin: Fix 64bit divisions > drm/hisilicon/kirin: Fix MASK(32) on 32bit architectures > drm/hisilicon/kirin: Allow build with COMPILE_TEST=y > drm/omap: Open code phys_to_page() > drm/omap: Allow build with COMPILE_TEST=y > drm/atmel-hlcdc: Allow build with COMPILE_TEST=y > drm/rcar-du: Allow build with COMPILE_TEST=y > drm/stm: Allow build with COMPILE_TEST=y ^ pushed to drm-misc-next. Thanks for the reviews. > drm/armada: Fix printk arguments > drm/armada: Fix armada_debugfs_crtc_reg_write() return type > drm/armada: Allow build with COMPILE_TEST=y > drm/imx/dcss: Fix 64bit divisions > drm/imx/dcss: Allow build with COMPILE_TEST=y > drm/sti: Include linux/io.h for devm_ioremap() > drm/sti: Allow build with COMPILE_TEST=y > drm/fsl-dcu: Allow build with COMPILE_TEST=y > drm/mediatek: Allow build with COMPILE_TEST=y > drm/meson: Allow build with COMPILE_TEST=y ^ are all still without comments. > drm/tilcdc: Allow build without __iowmb() > drm/tilcdc: Allow build with COMPILE_TEST=y ^ I need to respin. -- Ville Syrjälä Intel
Re: [PATCH 3/5] drm/i915: Use drm_crtc_vblank_crtc()
On Wed, May 08, 2024 at 12:12:32PM +0300, Jani Nikula wrote: > On Mon, 08 Apr 2024, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Replace the open coded drm_crtc_vblank_crtc() with the real > > thing. > > > > Cc: intel-...@lists.freedesktop.org > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Jani Nikula Ta. Pushed this one to to drm-intel-next since drm_crtc_vblank_crtc() made it there in the meantime. -- Ville Syrjälä Intel
Re: [PATCH 2/5] drm/amdgpu: Use drm_crtc_vblank_crtc()
On Wed, May 08, 2024 at 09:47:50AM -0400, Alex Deucher wrote: > On Mon, Apr 8, 2024 at 3:06 PM Ville Syrjala > wrote: > > > > From: Ville Syrjälä > > > > Replace the open coded drm_crtc_vblank_crtc() with the real > > thing. > > > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: "Pan, Xinhui" > > Cc: amd-...@lists.freedesktop.org > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Alex Deucher Thanks. Pushed to drm-misc-next. -- Ville Syrjälä Intel
Re: [PATCH] drm/uapi: Move drm_color_ctm_3x4 out from drm_mode.h
On Wed, Apr 24, 2024 at 03:48:24PM +, Simon Ser wrote: > On Monday, April 22nd, 2024 at 10:58, Ville Syrjala > wrote: > > > drm_color_ctm_3x4 is some undocumented amgdpu private > > uapi and thus has no business being in drm_mode.h. > > At least move it to some amdgpu specific header, albeit > > with the wrong namespace as maybe something somewhere > > is using this already? > > If something somewhere is using this already, I don't think the name > matters? In other words, if there is a user, such user would be broken > when moving the declaration anyways, so it shouldn't be more risky to > do the rename as well? I suppose. Not something I want to have to think about though. I've pushed this to drm-misc-next with Harry's rb (thanks). > > I'm holding off the libdrm header update until we find a solution. -- Ville Syrjälä Intel
Re: [PATCH v2] drivers/i915/intel_bios: Fix parsing backlight BDB data
On Wed, Feb 21, 2024 at 06:06:24PM -0700, Karthikeyan Ramasubramanian wrote:
> Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
> backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
> contents") updated the backlight BDB data accordingly. This broke the
> parsing of backlight BDB data in VBT for versions 236 - 238 (both
> inclusive) and hence the backlight controls are not responding on units
> with the concerned BDB version.
>
> backlight_control information has been present in backlight BDB data
> from at least BDB version 191 onwards, if not before. Hence this patch
> extracts the backlight_control information for BDB version 191 or newer.
> Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236).
> Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251).
>
> Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents")
> Cc: sta...@vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Karthikeyan Ramasubramanian
> ---
>
> Changes in v2:
> - removed checking the block size of the backlight BDB data
I fixed up the formatting of the commit message a bit,
added a note indicating why it's ok to remove the size
checks, and pushed to drm-intel-next. Thanks.
>
> drivers/gpu/drm/i915/display/intel_bios.c | 19 ---
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 -
> 2 files changed, 4 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index aa169b0055e97..8c1eb05fe77d2 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1042,22 +1042,11 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> panel->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> panel->vbt.backlight.controller = 0;
> if (i915->display.vbt.version >= 191) {
> - size_t exp_size;
> + const struct lfp_backlight_control_method *method;
>
> - if (i915->display.vbt.version >= 236)
> - exp_size = sizeof(struct bdb_lfp_backlight_data);
> - else if (i915->display.vbt.version >= 234)
> - exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> - else
> - exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_191;
> -
> - if (get_blocksize(backlight_data) >= exp_size) {
> - const struct lfp_backlight_control_method *method;
> -
> - method = _data->backlight_control[panel_type];
> - panel->vbt.backlight.type = method->type;
> - panel->vbt.backlight.controller = method->controller;
> - }
> + method = _data->backlight_control[panel_type];
> + panel->vbt.backlight.type = method->type;
> + panel->vbt.backlight.controller = method->controller;
> }
>
> panel->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index a9f44abfc9fc2..b50cd0dcabda9 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -897,11 +897,6 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> -#define EXP_BDB_LFP_BL_DATA_SIZE_REV_191 \
> - offsetof(struct bdb_lfp_backlight_data, brightness_level)
> -#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> - offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
> -
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
> --
> 2.44.0.rc0.258.g7320e95886-goog
--
Ville Syrjälä
Intel
Re: [PATCH 1/5] drm/vblank: Introduce drm_crtc_vblank_crtc()
On Tue, Apr 09, 2024 at 06:02:49PM +0300, Dmitry Baryshkov wrote: > On Mon, Apr 08, 2024 at 10:06:07PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Make life easier by providing a function that hands > > out the the correct drm_vblank_crtc for a given a drm_crtc. > > > > Also abstract the lower level internals of the vblank > > code in a similar fashion. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_vblank.c | 58 ++- > > drivers/gpu/drm/drm_vblank_work.c | 2 +- > > include/drm/drm_vblank.h | 1 + > > 3 files changed, 36 insertions(+), 25 deletions(-) > > > Reviewed-by: Dmitry Baryshkov > > I'm looking forward to using this in drm/msm This+nouveau+vkms parts push to the drm-misc-next. Thanks for the reviews. amdgpu and i915 parts still pending. -- Ville Syrjälä Intel
Re: [PATCH v11 19/28] drm/connector: hdmi: Add RGB Quantization Range to the connector state
cast RGB selection value. >*/ > enum drm_hdmi_broadcast_rgb broadcast_rgb; > > + /** > + * @is_full_range: Is the output supposed to use a full > + * RGB Quantization Range or not? > + */ > + bool is_full_range; I would say limited range is the exception so I would suggest flagging that instead. Feels a bit weird to flag the normal case. Maybe the name should also include 'rgb' to make it clear it only applies to RGB. > + > /** >* @output_bpc: Bits per color channel to output. >*/ > unsigned int output_bpc; > > > -- > 2.44.0 -- Ville Syrjälä Intel
Re: [PATCH v11 17/28] drm/connector: hdmi: Add Broadcast RGB property
_LIMITED: Limited range RGB is forced.
> + */
> + DRM_HDMI_BROADCAST_RGB_LIMITED,
> +};
> +
> +const char *
> +drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb
> broadcast_rgb);
> const char *
> drm_hdmi_connector_get_output_format_name(enum hdmi_colorspace fmt);
>
> /**
> * struct drm_monitor_range_info - Panel's Monitor range in EDID for
> @@ -1039,10 +1062,16 @@ struct drm_connector_state {
> /**
>* @hdmi: HDMI-related variable and properties. Filled by
>* @drm_atomic_helper_connector_hdmi_check().
>*/
> struct {
> + /**
> + * @broadcast_rgb: Connector property to pass the
> + * Broadcast RGB selection value.
> + */
> + enum drm_hdmi_broadcast_rgb broadcast_rgb;
> +
> /**
>* @output_bpc: Bits per color channel to output.
>*/
> unsigned int output_bpc;
>
> @@ -1751,10 +1780,16 @@ struct drm_connector {
>* @privacy_screen_hw_state_property: Optional atomic property for the
>* connector to report the actual integrated privacy screen state.
>*/
> struct drm_property *privacy_screen_hw_state_property;
>
> + /**
> + * @broadcast_rgb_property: Connector property to set the
> + * Broadcast RGB selection to output with.
> + */
> + struct drm_property *broadcast_rgb_property;
> +
> #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
> #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
>
> /**
> @@ -2090,10 +2125,11 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> u32 scaling_mode_mask);
> int drm_connector_attach_vrr_capable_property(
> struct drm_connector *connector);
> +int drm_connector_attach_broadcast_rgb_property(struct drm_connector
> *connector);
> int drm_connector_attach_colorspace_property(struct drm_connector
> *connector);
> int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
> *connector);
> bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state
> *old_state,
>struct drm_connector_state
> *new_state);
> int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>
> --
> 2.44.0
--
Ville Syrjälä
Intel
Re: [PATCH v11 15/28] drm/connector: hdmi: Compute bpc and format automatically
e->hdisplay, mode->vdisplay,
> drm_mode_vrefresh(mode),
> + conn_state->hdmi.output_bpc,
> +
> drm_hdmi_connector_get_output_format_name(conn_state->hdmi.output_format),
> + conn_state->hdmi.tmds_char_rate);
> +
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> /**
> * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector
> atomic state
> * @connector: DRM Connector
> * @state: the DRM State object
> *
> @@ -113,13 +306,11 @@ int drm_atomic_helper_connector_hdmi_check(struct
> drm_connector *connector,
> drm_atomic_get_new_connector_state(state, connector);
> const struct drm_display_mode *mode =
> connector_state_get_mode(new_conn_state);
> int ret;
>
> - ret = hdmi_compute_clock(connector, new_conn_state, mode,
> - new_conn_state->hdmi.output_bpc,
> - new_conn_state->hdmi.output_format);
> + ret = hdmi_compute_config(connector, new_conn_state, mode);
> if (ret)
> return ret;
>
> if (old_conn_state->hdmi.output_bpc != new_conn_state->hdmi.output_bpc
> ||
> old_conn_state->hdmi.output_format !=
> new_conn_state->hdmi.output_format) {
> diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> index ead998a691e7..a49a544d7b49 100644
> --- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> @@ -70,13 +70,10 @@ static int light_up_connector(struct kunit *test,
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
>
> conn_state = drm_atomic_get_connector_state(state, connector);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
>
> - conn_state->hdmi.output_bpc = connector->max_bpc;
> - conn_state->hdmi.output_format = HDMI_COLORSPACE_RGB;
> -
> ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
> KUNIT_EXPECT_EQ(test, ret, 0);
>
> crtc_state = drm_atomic_get_crtc_state(state, crtc);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
> @@ -251,14 +248,19 @@ static void
> drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
> priv = drm_atomic_helper_connector_hdmi_init(test,
>BIT(HDMI_COLORSPACE_RGB),
>10);
> KUNIT_ASSERT_NOT_NULL(test, priv);
>
> + conn = >connector;
> + ret = set_connector_edid(test, conn,
> + test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +
> ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> + KUNIT_ASSERT_EQ(test, ret, 0);
> +
> ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
>
> - conn = >connector;
> preferred = find_preferred_mode(conn);
> KUNIT_ASSERT_NOT_NULL(test, preferred);
>
> drm = >drm;
> crtc = priv->crtc;
> @@ -272,15 +274,15 @@ static void
> drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
>
> old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
>
> - new_conn_state->hdmi.output_bpc = 8;
> + new_conn_state->max_requested_bpc = 8;
>
> KUNIT_ASSERT_NE(test,
> - old_conn_state->hdmi.output_bpc,
> - new_conn_state->hdmi.output_bpc);
> + old_conn_state->max_requested_bpc,
> + new_conn_state->max_requested_bpc);
>
> ret = drm_atomic_check_only(state);
> KUNIT_ASSERT_EQ(test, ret, 0);
>
> old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> @@ -320,14 +322,19 @@ static void
> drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
> priv = drm_atomic_helper_connector_hdmi_init(test,
>BIT(HDMI_COLORSPACE_RGB),
>10);
> KUNIT_ASSERT_NOT_NULL(test, priv);
>
> + conn = >connector;
> + ret = set_connector_edid(test, conn,
> + test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +
> ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> + KUNIT_ASSERT_EQ(test, ret, 0);
> +
> ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
>
> - conn = >connector;
> preferred = find_preferred_mode(conn);
> KUNIT_ASSERT_NOT_NULL(test, preferred);
>
> drm = >drm;
> crtc = priv->crtc;
> @@ -670,11 +677,11 @@ static void drm_test_check_format_value(struct kunit
> *test)
>8);
> KUNIT_ASSERT_NOT_NULL(test, priv);
>
> conn = >connector;
> conn_state = conn->state;
> - KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format,
> HDMI_COLORSPACE_RGB);
> + KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, 0);
> }
>
> /*
> * Test that the value of the output format property out of reset is set
> * to 0, and will be computed at atomic_check time.
>
> --
> 2.44.0
--
Ville Syrjälä
Intel
Re: [PATCH v11 09/28] drm/display: hdmi: Add HDMI compute clock helper
On Tue, Mar 26, 2024 at 04:40:13PM +0100, Maxime Ripard wrote:
> A lot of HDMI drivers have some variation of the formula to calculate
> the TMDS character rate from a mode, but few of them actually take all
> parameters into account.
>
> Let's create a helper to provide that rate taking all parameters into
> account.
>
> Reviewed-by: Dave Stevenson
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/display/drm_hdmi_helper.c | 70
> +++
> include/drm/display/drm_hdmi_helper.h | 4 ++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
> b/drivers/gpu/drm/display/drm_hdmi_helper.c
> index faf5e9efa7d3..2518dd1a07e7 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> @@ -193,5 +193,75 @@ void drm_hdmi_avi_infoframe_content_type(struct
> hdmi_avi_infoframe *frame,
> }
>
> frame->itc = conn_state->content_type != DRM_MODE_CONTENT_TYPE_NO_DATA;
> }
> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_content_type);
> +
> +/**
> + * drm_hdmi_compute_mode_clock() - Computes the TMDS Character Rate
> + * @mode: Display mode to compute the clock for
> + * @bpc: Bits per character
> + * @fmt: Output Pixel Format used
> + *
> + * Returns the TMDS Character Rate for a given mode, bpc count and output
> format.
> + *
> + * RETURNS:
> + * The TMDS Character Rate, in Hertz, or 0 on error.
Everything generally uses kHz. Sticking to common units
would be better.
> + */
> +unsigned long long
> +drm_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
> + unsigned int bpc, enum hdmi_colorspace fmt)
> +{
> + unsigned long long clock = mode->clock * 1000ULL;
> + unsigned int vic = drm_match_cea_mode(mode);
> +
> + /*
> + * CTA-861-G Spec, section 5.4 - Color Coding and Quantization
> + * mandates that VIC 1 always uses 8 bpc.
> + */
> + if (vic == 1 && bpc != 8)
> + return 0;
> +
> + /*
> + * HDMI 2.0 Spec, section 7.1 - YCbCr 4:2:0 Pixel Encoding
> + * specifies that YUV420 encoding is only available for those
> + * VICs.
> + */
> + if (fmt == HDMI_COLORSPACE_YUV420 &&
> + !(vic == 96 || vic == 97 || vic == 101 ||
> + vic == 102 || vic == 106 || vic == 107))
> + return 0;
I believe that is already outdated. I would just rip this out since the
sink is anyway required to declare for which timings it will support
4:2:0 via the Y420CMDB/VDB data blocks (see
drm_mode_is_420_{only,also}().
> +
> + if (fmt == HDMI_COLORSPACE_YUV422) {
> + /*
> + * HDMI 1.4b Spec, section 6.2.3 - Pixel Encoding Requirements
> + * specifies that YUV422 is 36-bit only.
> + */
> + if (bpc != 12)
> + return 0;
> +
> + /*
> + * HDMI 1.0 Spec, section 6.5 - Pixel Encoding
> + * specifies that YUV422 requires two 12-bits components per
> + * pixel clock, which is equivalent in our calculation to three
> + * 8-bits components
> + */
> + bpc = 8;
> + }
> +
> + /*
> + * HDMI 2.0 Spec, Section 7.1 - YCbCr 4:2:0 Pixel Encoding
> + * specifies that YUV420 encoding is carried at a TMDS Character Rate
> + * equal to half the pixel clock rate.
> + */
> + if (fmt == HDMI_COLORSPACE_YUV420)
> + clock = clock / 2;
> +
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> + clock = clock * 2;
> +
> + clock = clock * bpc;
> + do_div(clock, 8);
IMO one shouldn't use bare do_div(). There are
more sensible wrappers for it.
In this case I would use DIV_ROUND_CLOSEST_ULL().
Although the 64bit math is not even required if you
just stick to kHz like everyone else.
> +
> + return clock;
> +}
> +EXPORT_SYMBOL(drm_hdmi_compute_mode_clock);
> diff --git a/include/drm/display/drm_hdmi_helper.h
> b/include/drm/display/drm_hdmi_helper.h
> index 76d234826e22..57e3b18c15ec 100644
> --- a/include/drm/display/drm_hdmi_helper.h
> +++ b/include/drm/display/drm_hdmi_helper.h
> @@ -22,6 +22,10 @@ drm_hdmi_infoframe_set_hdr_metadata(struct
> hdmi_drm_infoframe *frame,
> const struct drm_connector_state
> *conn_state);
>
> void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame,
>const struct drm_connector_state
> *conn_state);
>
> +unsigned long long
> +drm_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
> + unsigned int bpc, enum hdmi_colorspace fmt);
> +
> #endif
>
> --
> 2.44.0
--
Ville Syrjälä
Intel
Re: [PATCH 12/21] drm/tilcdc: Allow build without __iowmb()
On Wed, Apr 10, 2024 at 06:25:17PM +0300, Ville Syrjälä wrote: > On Wed, Apr 10, 2024 at 12:06:29PM +0300, Tomi Valkeinen wrote: > > On 08/04/2024 20:04, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > __iowmb() isn't available on most architectures. Make > > > its use optional so that the driver can be built on > > > other architectures with COMPILE_TEST=y. > > > > > > Cc: Jyri Sarha > > > Cc: Tomi Valkeinen > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > > b/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > > index f90e2dc3457c..44e4ada30fba 100644 > > > --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > > +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > > @@ -125,7 +125,9 @@ static inline void tilcdc_write64(struct drm_device > > > *dev, u32 reg, u64 data) > > > #if defined(iowrite64) && !defined(iowrite64_is_nonatomic) > > > iowrite64(data, addr); > > > #else > > > +#ifdef __iowmb > > > __iowmb(); > > > +#endif > > > /* This compiles to strd (=64-bit write) on ARM7 */ > > > *(volatile u64 __force *)addr = __cpu_to_le64(data); > > > #endif > > > > As the memory barrier is an important part there, would it be better to > > ifdef based on COMPILE_TEST, to make it clear why it's being done? > > I can do that if you prefer. What if someone tries to actually boot a kernel built with COMPILE_TEST=y on a machine with this hardware? -- Ville Syrjälä Intel
Re: [PATCH 12/21] drm/tilcdc: Allow build without __iowmb()
On Wed, Apr 10, 2024 at 12:06:29PM +0300, Tomi Valkeinen wrote: > On 08/04/2024 20:04, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > __iowmb() isn't available on most architectures. Make > > its use optional so that the driver can be built on > > other architectures with COMPILE_TEST=y. > > > > Cc: Jyri Sarha > > Cc: Tomi Valkeinen > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > b/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > index f90e2dc3457c..44e4ada30fba 100644 > > --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h > > @@ -125,7 +125,9 @@ static inline void tilcdc_write64(struct drm_device > > *dev, u32 reg, u64 data) > > #if defined(iowrite64) && !defined(iowrite64_is_nonatomic) > > iowrite64(data, addr); > > #else > > +#ifdef __iowmb > > __iowmb(); > > +#endif > > /* This compiles to strd (=64-bit write) on ARM7 */ > > *(volatile u64 __force *)addr = __cpu_to_le64(data); > > #endif > > As the memory barrier is an important part there, would it be better to > ifdef based on COMPILE_TEST, to make it clear why it's being done? I can do that if you prefer. I suppose the real question is why iowrite64() doesn't work if a hand rolled version does work? -- Ville Syrjälä Intel
Re: [PATCH v2 3/4] drm/i915/bios: switch to struct drm_edid and struct drm_edid_product_id
On Tue, Apr 09, 2024 at 12:46:11PM +0300, Jani Nikula wrote:
> To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch
> to the struct drm_edid based function to extract product id, and use the
> drm printer function to debug log it.
>
> The underlying assumption is that struct drm_edid_product_id and struct
> lvds_pnp_id describe identical data, albeit with slightly different
> member definitions.
>
> Cc: Ville Syrjälä
> Acked-by: Melissa Wen
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 43 ++-
> 1 file changed, 18 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 2abd2d7ceda2..3d89e4b39fed 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -600,6 +600,9 @@ get_lvds_pnp_id(const struct bdb_lvds_lfp_data *data,
> const struct bdb_lvds_lfp_data_ptrs *ptrs,
> int index)
> {
> + /* These two are supposed to have the same layout in memory. */
> + BUILD_BUG_ON(sizeof(struct lvds_pnp_id) != sizeof(struct
> drm_edid_product_id));
> +
> return (const void *)data + ptrs->ptr[index].panel_pnp_id.offset;
> }
>
> @@ -613,19 +616,6 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
> return NULL;
> }
>
> -static void dump_pnp_id(struct drm_i915_private *i915,
> - const struct lvds_pnp_id *pnp_id,
> - const char *name)
> -{
> - u16 mfg_name = be16_to_cpu((__force __be16)pnp_id->mfg_name);
> - char vend[4];
> -
> - drm_dbg_kms(>drm, "%s PNPID mfg: %s (0x%x), prod: %u, serial: %u,
> week: %d, year: %d\n",
> - name, drm_edid_decode_mfg_id(mfg_name, vend),
> - pnp_id->mfg_name, pnp_id->product_code, pnp_id->serial,
> - pnp_id->mfg_week, pnp_id->mfg_year + 1990);
> -}
> -
> static int opregion_get_panel_type(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data
> *devdata,
> const struct drm_edid *drm_edid, bool
> use_fallback)
> @@ -664,21 +654,21 @@ static int pnpid_get_panel_type(struct drm_i915_private
> *i915,
> {
> const struct bdb_lvds_lfp_data *data;
> const struct bdb_lvds_lfp_data_ptrs *ptrs;
> - const struct lvds_pnp_id *edid_id;
> - struct lvds_pnp_id edid_id_nodate;
> - const struct edid *edid = drm_edid_raw(drm_edid); /* FIXME */
> + struct drm_edid_product_id product_id, product_id_nodate;
> + struct drm_printer p;
> int i, best = -1;
>
> - if (!edid)
> + if (!drm_edid)
> return -1;
>
> - edid_id = (const void *)>mfg_id[0];
> + drm_edid_get_product_id(drm_edid, _id);
I don't really like s/edid_id/product_id/ rename.
The variable names were trying to convey the source of
the data (EDID vs. VBT).
But not a huge deal wither way. Series is
Reviewed-by: Ville Syrjälä
>
> - edid_id_nodate = *edid_id;
> - edid_id_nodate.mfg_week = 0;
> - edid_id_nodate.mfg_year = 0;
> + product_id_nodate = product_id;
> + product_id_nodate.week_of_manufacture = 0;
> + product_id_nodate.year_of_manufacture = 0;
>
> - dump_pnp_id(i915, edid_id, "EDID");
> + p = drm_dbg_printer(>drm, DRM_UT_KMS, "EDID");
> + drm_edid_print_product_id(, _id, true);
>
> ptrs = bdb_find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> if (!ptrs)
> @@ -693,7 +683,7 @@ static int pnpid_get_panel_type(struct drm_i915_private
> *i915,
> get_lvds_pnp_id(data, ptrs, i);
>
> /* full match? */
> - if (!memcmp(vbt_id, edid_id, sizeof(*vbt_id)))
> + if (!memcmp(vbt_id, _id, sizeof(*vbt_id)))
> return i;
>
> /*
> @@ -701,7 +691,7 @@ static int pnpid_get_panel_type(struct drm_i915_private
> *i915,
>* and the VBT entry does not specify a date.
>*/
> if (best < 0 &&
> - !memcmp(vbt_id, _id_nodate, sizeof(*vbt_id)))
> + !memcmp(vbt_id, _id_nodate, sizeof(*vbt_id)))
> best = i;
> }
>
> @@ -888,6 +878,7 @@ parse_lfp_data(struct drm_i915_private *i915,
> const struct bdb_lvds_lfp_data_tail *tail;
> const struct bdb_lvds_lfp_data_ptrs *ptrs;
> const struct lvds_pnp_id *pnp_id;
> + struct drm_printer p;
> int panel_type = panel->vb
Re: [PATCH 1/4] drm/edid: add drm_edid_get_product_id()
On Thu, Mar 21, 2024 at 12:05:09PM +0200, Jani Nikula wrote:
> Add a struct drm_edid based function to get the vendor and product ID
> from an EDID. Add a separate struct for defining this part of the EDID,
> with defined byte order for product code and serial number.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 15 +++
> include/drm/drm_edid.h | 25 -
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ea77577a3786..626a0e24e66a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2756,6 +2756,21 @@ const struct drm_edid *drm_edid_read(struct
> drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_edid_read);
>
> +/**
> + * drm_edid_get_product_id - Get the vendor and product identification
> + * @drm_edid: EDID
> + * @id: Where to place the product id
> + */
> +void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> + struct drm_edid_product_id *id)
> +{
> + if (drm_edid && drm_edid->edid && drm_edid->size >= EDID_LENGTH)
> + memcpy(id, _edid->edid->product_id, sizeof(*id));
> + else
> + memset(id, 0, sizeof(*id));
> +}
> +EXPORT_SYMBOL(drm_edid_get_product_id);
> +
> /**
> * drm_edid_get_panel_id - Get a panel's ID from EDID
> * @drm_edid: EDID that contains panel ID.
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 6f65bbf655a1..7911a2f8a672 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -272,14 +272,27 @@ struct detailed_timing {
> #define DRM_EDID_DSC_MAX_SLICES 0xf
> #define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES 0x3f
>
> +struct drm_edid_product_id {
> + u8 manufacturer_name[2];
__be16?
> + __le16 product_code;
> + __le32 serial_number;
> + u8 week_of_manufacture;
> + u8 year_of_manufacture;
> +} __packed;
> +
> struct edid {
> u8 header[8];
> /* Vendor & product info */
> - u8 mfg_id[2];
> - u8 prod_code[2];
> - u32 serial; /* FIXME: byte order */
> - u8 mfg_week;
> - u8 mfg_year;
> + union {
> + struct drm_edid_product_id product_id;
> + struct {
> + u8 mfg_id[2];
> + u8 prod_code[2];
> + u32 serial; /* FIXME: byte order */
> + u8 mfg_week;
> + u8 mfg_year;
> + } __packed;
> + } __packed;
> /* EDID version */
> u8 version;
> u8 revision;
> @@ -466,6 +479,8 @@ int drm_edid_connector_update(struct drm_connector
> *connector,
> const struct drm_edid *edid);
> int drm_edid_connector_add_modes(struct drm_connector *connector);
> bool drm_edid_is_digital(const struct drm_edid *drm_edid);
> +void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> + struct drm_edid_product_id *id);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH 2/4] drm/edid: add drm_edid_print_product_id()
On Thu, Mar 21, 2024 at 12:05:10PM +0200, Jani Nikula wrote:
> Add a function to print a decoded EDID vendor and product id to a drm
> printer, optinally with the raw data.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 35 +++
> include/drm/drm_edid.h | 3 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 626a0e24e66a..198986f0eb8b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -29,6 +29,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -2771,6 +2772,40 @@ void drm_edid_get_product_id(const struct drm_edid
> *drm_edid,
> }
> EXPORT_SYMBOL(drm_edid_get_product_id);
>
> +/**
> + * drm_edid_print_product_id - Print decoded product id to printer
> + * @p: drm printer
> + * @id: EDID product id
> + * @raw: If true, also print the raw hex
> + */
> +void drm_edid_print_product_id(struct drm_printer *p,
> +const struct drm_edid_product_id *id, bool raw)
> +{
> + u16 mfg_id = id->manufacturer_name[0] << 8 | id->manufacturer_name[1];
> + char *date;
> + char vend[4];
> +
> + drm_edid_decode_mfg_id(mfg_id, vend);
> +
> + if (id->week_of_manufacture == 0xff)
Didn't realize this had a loaded meaning. Maybe we should also
skip the week printout if week==0? Otherwise people might think
week==0 means the first week.
> + date = kasprintf(GFP_KERNEL, "model year: %d",
> + id->year_of_manufacture + 1990);
> + else
> + date = kasprintf(GFP_KERNEL, "week: %d, year of manufacture:
> %d",
The "week: %d" part feels a bit left out here. Maybe this should be
formatted as "week/year of manufacture: %d/%d"?
Not sure I like the kasprintf(). Maybe use an on-stack buffer?
> + id->week_of_manufacture,
> + id->year_of_manufacture + 1990);
> +
> + drm_printf(p, "manufacturer name: %s, product code: %u, serial number:
> %u, %s\n",
> +vend, le16_to_cpu(id->product_code),
> +le32_to_cpu(id->serial_number), date ?: "");
> +
> + if (raw)
> + drm_printf(p, "raw product id: %*ph\n", (int)sizeof(*id), id);
> +
> + kfree(date);
> +}
> +EXPORT_SYMBOL(drm_edid_print_product_id);
> +
> /**
> * drm_edid_get_panel_id - Get a panel's ID from EDID
> * @drm_edid: EDID that contains panel ID.
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7911a2f8a672..c763ba1a0bbd 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -30,6 +30,7 @@ struct drm_connector;
> struct drm_device;
> struct drm_display_mode;
> struct drm_edid;
> +struct drm_printer;
> struct hdmi_avi_infoframe;
> struct hdmi_vendor_infoframe;
> struct i2c_adapter;
> @@ -481,6 +482,8 @@ int drm_edid_connector_add_modes(struct drm_connector
> *connector);
> bool drm_edid_is_digital(const struct drm_edid *drm_edid);
> void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> struct drm_edid_product_id *id);
> +void drm_edid_print_product_id(struct drm_printer *p,
> +const struct drm_edid_product_id *id, bool raw);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH 11/12] drm/client: Streamline mode selection debugs
On Mon, Apr 08, 2024 at 09:46:44AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.24 um 21:58 schrieb Ville Syrjälä:
> > On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
> >>> From: Ville Syrjälä
> >>>
> >>> Get rid of all the redundant debugs and just wait until the end
> >>> to print which mode (and of which type) we picked.
> >>>
> >>> Signed-off-by: Ville Syrjälä
> >>> ---
> >>>drivers/gpu/drm/drm_client_modeset.c | 65 +---
> >>>1 file changed, 31 insertions(+), 34 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> >>> b/drivers/gpu/drm/drm_client_modeset.c
> >>> index 415d1799337b..ad88c11037d8 100644
> >>> --- a/drivers/gpu/drm/drm_client_modeset.c
> >>> +++ b/drivers/gpu/drm/drm_client_modeset.c
> >>> @@ -408,6 +408,8 @@ static bool drm_client_target_preferred(struct
> >>> drm_device *dev,
> >>>
> >>>retry:
> >>> for (i = 0; i < connector_count; i++) {
> >>> + const char *mode_type;
> >>> +
> >>> connector = connectors[i];
> >>>
> >>> if (conn_configured & BIT_ULL(i))
> >>> @@ -440,20 +442,20 @@ static bool drm_client_target_preferred(struct
> >>> drm_device *dev,
> >>> drm_client_get_tile_offsets(dev, connectors,
> >>> connector_count, modes, offsets, i,
> >>>
> >>> connector->tile_h_loc, connector->tile_v_loc);
> >>> }
> >>> - drm_dbg_kms(dev, "looking for cmdline mode on
> >>> [CONNECTOR:%d:%s]\n",
> >>> - connector->base.id, connector->name);
> >>>
> >>> - /* got for command line mode first */
> >>> + mode_type = "cmdline";
> >>> modes[i] = drm_connector_pick_cmdline_mode(connector);
> >>> +
> >>> if (!modes[i]) {
> >>> - drm_dbg_kms(dev, "looking for preferred mode on
> >>> [CONNECTOR:%d:%s] (tile group: %d)\n",
> >>> - connector->base.id, connector->name,
> >>> - connector->tile_group ?
> >>> connector->tile_group->id : 0);
> >>> + mode_type = "preferred";
> >>> modes[i] =
> >>> drm_connector_preferred_mode(connector, width, height);
> >>> }
> >>> - /* No preferred modes, pick one off the list */
> >>> - if (!modes[i])
> >>> +
> >>> + if (!modes[i]) {
> >>> + mode_type = "first";
> >>> modes[i] = drm_connector_first_mode(connector);
> >>> + }
> >>> +
> >>> /*
> >>>* In case of tiled mode if all tiles not present
> >>> fallback to
> >>>* first available non tiled mode.
> >>> @@ -468,16 +470,20 @@ static bool drm_client_target_preferred(struct
> >>> drm_device *dev,
> >>> (connector->tile_h_loc == 0 &&
> >>>connector->tile_v_loc == 0 &&
> >>>!drm_connector_get_tiled_mode(connector)))
> >>> {
> >>> - drm_dbg_kms(dev, "Falling back to non tiled
> >>> mode on [CONNECTOR:%d:%s]\n",
> >>> - connector->base.id,
> >>> connector->name);
> >>> + mode_type = "non tiled";
> >>> modes[i] =
> >>> drm_connector_fallback_non_tiled_mode(connector);
> >>> } else {
> >>> + mode_type = "tiled";
> >>> modes[i] =
> >>> drm_connector_get_tiled_mode(connector);
> >>> }
> >>> }
> >&g
Re: [PATCH 15/21] drm/omap: Allow build with COMPILE_TEST=y
On Mon, Apr 08, 2024 at 08:04:20PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Allow omapdrm to be built with COMPILE_TEST=y for greater > coverage. > > FIXME: Still borked due to ? In fact not borked anymore. Just forgot to update the commit message. > > Cc: Tomi Valkeinen > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/omapdrm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig > index 6c49270cb290..85ed92042b74 100644 > --- a/drivers/gpu/drm/omapdrm/Kconfig > +++ b/drivers/gpu/drm/omapdrm/Kconfig > @@ -2,7 +2,7 @@ > config DRM_OMAP > tristate "OMAP DRM" > depends on DRM && OF > - depends on ARCH_OMAP2PLUS > + depends on ARCH_OMAP2PLUS || COMPILE_TEST > select DRM_KMS_HELPER > select FB_DMAMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION > select VIDEOMODE_HELPERS > -- > 2.43.2 -- Ville Syrjälä Intel
Re: [PATCH v2 7/7] drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()
On Mon, Apr 08, 2024 at 12:24:02PM +0300, Jani Nikula wrote:
> We have DRM_MODE_FMT and DRM_MODE_ARG() macros to allow unified debug
> printing of modes in any printk-formatted logging. Prefer them over
> drm_mode_debug_printmodeline().
>
> This allows drm device specific logging of modes, in the right drm debug
> category, and inline with the rest of the logging instead of split to
> multiple lines.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 6 +++---
> drivers/gpu/drm/drm_crtc.c | 6 +++---
> drivers/gpu/drm/drm_crtc_helper.c | 9 -
> drivers/gpu/drm/drm_modes.c| 13 +
> drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> 5 files changed, 17 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d4..fc16fddee5c5 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -145,10 +145,10 @@ int drm_atomic_set_mode_prop_for_crtc(struct
> drm_crtc_state *state,
>>mode, blob->data);
> if (ret) {
> drm_dbg_atomic(crtc->dev,
> -"[CRTC:%d:%s] invalid mode (ret=%d,
> status=%s):\n",
> +"[CRTC:%d:%s] invalid mode (%s, %pe): "
> DRM_MODE_FMT "\n",
> crtc->base.id, crtc->name,
> -ret,
> drm_get_mode_status_name(state->mode.status));
> - drm_mode_debug_printmodeline(>mode);
> +
> drm_get_mode_status_name(state->mode.status),
> +ERR_PTR(ret),
> DRM_MODE_ARG(>mode));
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b0a0e27e83eb..483969b84a30 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -775,9 +775,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>
> ret = drm_mode_convert_umode(dev, mode, _req->mode);
> if (ret) {
> - drm_dbg_kms(dev, "Invalid mode (ret=%d, status=%s)\n",
> - ret,
> drm_get_mode_status_name(mode->status));
> - drm_mode_debug_printmodeline(mode);
> + drm_dbg_kms(dev, "Invalid mode (%s, %pe): "
> DRM_MODE_FMT "\n",
> + drm_get_mode_status_name(mode->status),
> + ERR_PTR(ret), DRM_MODE_ARG(mode));
> goto out;
> }
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index af7ac9d9192a..0955f1c385dd 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -657,8 +657,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> if (!drm_mode_equal(set->mode, >crtc->mode)) {
> drm_dbg_kms(dev, "[CRTC:%d:%s] modes are different, full mode
> set:\n",
> set->crtc->base.id, set->crtc->name);
> - drm_mode_debug_printmodeline(>crtc->mode);
> - drm_mode_debug_printmodeline(set->mode);
> + drm_dbg_kms(dev, DRM_MODE_FMT "\n",
> DRM_MODE_ARG(>crtc->mode));
> + drm_dbg_kms(dev, DRM_MODE_FMT "\n", DRM_MODE_ARG(set->mode));
> mode_changed = true;
> }
>
> @@ -766,9 +766,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>
> if (mode_changed) {
> if (drm_helper_crtc_in_use(set->crtc)) {
> - drm_dbg_kms(dev, "[CRTC:%d:%s] attempting to set mode
> from userspace\n",
> - set->crtc->base.id, set->crtc->name);
> - drm_mode_debug_printmodeline(set->mode);
> + drm_dbg_kms(dev, "[CRTC:%d:%s] attempting to set mode
> from userspace: " DRM_MODE_FMT "\n",
> + set->crtc->base.id, set->crtc->name,
> DRM_MODE_ARG(set->mode));
> set->crtc->primary->fb = set->fb;
> if (!drm_crtc_helper_set_mode(set->crtc, set->mode,
> set->x, set->y,
Re: [PATCH v2 6/7] drm/crtc-helper: switch to drm device based logging and warns
encoder->base.id, encoder->name, mode->name);
> + drm_dbg_kms(dev, "[ENCODER:%d:%s] set [MODE:%s]\n",
> + encoder->base.id, encoder->name, mode->name);
> if (encoder_funcs->mode_set)
> encoder_funcs->mode_set(encoder, mode, adjusted_mode);
> }
> @@ -503,7 +505,7 @@ drm_connector_get_single_encoder(struct drm_connector
> *connector)
> {
> struct drm_encoder *encoder;
>
> - WARN_ON(hweight32(connector->possible_encoders) > 1);
> + drm_WARN_ON(connector->dev, hweight32(connector->possible_encoders) >
> 1);
> drm_connector_for_each_possible_encoder(connector, encoder)
> return encoder;
>
> @@ -564,8 +566,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> int ret;
> int i;
>
> - DRM_DEBUG_KMS("\n");
> -
> BUG_ON(!set);
> BUG_ON(!set->crtc);
> BUG_ON(!set->crtc->helper_private);
> @@ -577,19 +577,22 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> crtc_funcs = set->crtc->helper_private;
>
> dev = set->crtc->dev;
> - WARN_ON(drm_drv_uses_atomic_modeset(dev));
> +
> + drm_dbg_kms(dev, "\n");
That looks rather redundant as we print something below anyway.
Could drop this as a followup I guess.
This patch looks fine regardless
Reviewed-by: Ville Syrjälä
> +
> + drm_WARN_ON(dev, drm_drv_uses_atomic_modeset(dev));
>
> if (!set->mode)
> set->fb = NULL;
>
> if (set->fb) {
> - DRM_DEBUG_KMS("[CRTC:%d:%s] [FB:%d] #connectors=%d (x y) (%i
> %i)\n",
> - set->crtc->base.id, set->crtc->name,
> - set->fb->base.id,
> - (int)set->num_connectors, set->x, set->y);
> + drm_dbg_kms(dev, "[CRTC:%d:%s] [FB:%d] #connectors=%d (x y) (%i
> %i)\n",
> + set->crtc->base.id, set->crtc->name,
> + set->fb->base.id,
> + (int)set->num_connectors, set->x, set->y);
> } else {
> - DRM_DEBUG_KMS("[CRTC:%d:%s] [NOFB]\n",
> - set->crtc->base.id, set->crtc->name);
> + drm_dbg_kms(dev, "[CRTC:%d:%s] [NOFB]\n",
> + set->crtc->base.id, set->crtc->name);
> drm_crtc_helper_disable(set->crtc);
> return 0;
> }
> @@ -639,7 +642,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> if (set->crtc->primary->fb != set->fb) {
> /* If we have no fb then treat it as a full mode set */
> if (set->crtc->primary->fb == NULL) {
> - DRM_DEBUG_KMS("crtc has no fb, full mode set\n");
> + drm_dbg_kms(dev, "[CRTC:%d:%s] no fb, full mode set\n",
> + set->crtc->base.id, set->crtc->name);
> mode_changed = true;
> } else if (set->fb->format != set->crtc->primary->fb->format) {
> mode_changed = true;
> @@ -651,7 +655,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> fb_changed = true;
>
> if (!drm_mode_equal(set->mode, >crtc->mode)) {
> - DRM_DEBUG_KMS("modes are different, full mode set\n");
> + drm_dbg_kms(dev, "[CRTC:%d:%s] modes are different, full mode
> set:\n",
> + set->crtc->base.id, set->crtc->name);
> drm_mode_debug_printmodeline(>crtc->mode);
> drm_mode_debug_printmodeline(set->mode);
> mode_changed = true;
> @@ -687,7 +692,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> fail = 1;
>
> if (connector->dpms != DRM_MODE_DPMS_ON) {
> - DRM_DEBUG_KMS("connector dpms not on,
> full mode switch\n");
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s]
> DPMS not on, full mode switch\n",
> + connector->base.id,
> connector->name);
> mode_changed = true;
> }
>
> @@ -696,7 +702,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>
Re: [PATCH 01/12] drm/client: Fully protect modes[] with dev->mode_config.mutex
On Fri, Apr 05, 2024 at 11:39:33PM +0300, Dmitry Baryshkov wrote:
> On Fri, 5 Apr 2024 at 22:17, Ville Syrjälä
> wrote:
> >
> > On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> > > On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > The modes[] array contains pointers to modes on the connectors'
> > > > mode lists, which are protected by dev->mode_config.mutex.
> > > > Thus we need to extend modes[] the same protection or by the
> > > > time we use it the elements may already be pointing to
> > > > freed/reused memory.
> > > >
> > > > Cc: sta...@vger.kernel.org
> > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583
> > > > Signed-off-by: Ville Syrjälä
> > >
> > > Reviewed-by: Dmitry Baryshkov
> > >
> > > I tried looking for the proper Fixes tag, but it looks like it might be
> > > something like 386516744ba4 ("drm/fb: fix fbdev object model + cleanup
> > > properly.")
> >
> > The history is rather messy. I think it was originally completely
> > lockless and broken, and got fixed piecemeal later in these:
> > commit 7394371d8569 ("drm: Take lock around probes for
> > drm_fb_helper_hotplug_event")
> > commit 966a6a13c666 ("drm: Hold mode_config.lock to prevent hotplug whilst
> > setting up crtcs")
> >
> > commit e13a05831050 ("drm/fb-helper: Stop using mode_config.mutex for
> > internals")
> > looks to me like where the race might have been re-introduced.
> > But didn't do a thorough analysis so not 100% sure. It's all
> > rather ancient history by now so a Fixes tag doesn't seem all
> > that useful anyway.
>
> Well, you have added stable to cc list, so you expect to have this
> patch backported. Then it should either have a kernel version as a
> 'starting' point or a Fixes tag to assist the sable team.
It'll get backported just fine without either.
--
Ville Syrjälä
Intel
Re: [PATCH 10/12] drm/client: Use [CONNECTOR:%d:%s] formatting
On Fri, Apr 05, 2024 at 11:23:01AM +0300, Jani Nikula wrote:
> On Thu, 04 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Switch to the canonical [CONNECTOR:%d:%s] etc. format for
> > printing out kms objects.
>
> I've been pinging for reviews on [1] for a while now. :/
>
> I'm just doing what you do in patches 9-10 in one go, and I very much
> prefer having the [CONNECTOR:%d:%s] bit as the first thing in the
> debug. For an individual line your style might read better, but for
> reading a log with a bunch of consecutive lines, I think having it as a
> prefix reads better.
>
> BR,
> Jani.
>
>
> [1]
> https://lore.kernel.org/r/f580f7a20bdea45178cef3940b636d491ae3dd92.1709843865.git.jani.nik...@intel.com
>
Looks like you have rbs now. I can rebase this
(and see what's left) after your stuff lands.
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_client_modeset.c | 65 +++-
> > 1 file changed, 35 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > b/drivers/gpu/drm/drm_client_modeset.c
> > index 1751162b7d5c..415d1799337b 100644
> > --- a/drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -251,8 +251,10 @@ static void drm_client_connectors_enabled(struct
> > drm_device *dev,
> > for (i = 0; i < connector_count; i++) {
> > connector = connectors[i];
> > enabled[i] = drm_connector_enabled(connector, true);
> > - drm_dbg_kms(dev, "connector %d enabled? %s\n",
> > connector->base.id,
> > - connector->display_info.non_desktop ? "non desktop"
> > : str_yes_no(enabled[i]));
> > + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] enabled? %s\n",
> > + connector->base.id, connector->name,
> > + connector->display_info.non_desktop ?
> > + "non desktop" : str_yes_no(enabled[i]));
> >
> > any_enabled |= enabled[i];
> > }
> > @@ -368,8 +370,8 @@ static int drm_client_get_tile_offsets(struct
> > drm_device *dev,
> > continue;
> >
> > if (!modes[i] && (h_idx || v_idx)) {
> > - drm_dbg_kms(dev, "no modes for connector tiled %d %d\n",
> > - i, connector->base.id);
> > + drm_dbg_kms(dev, "no modes for tiled
> > [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > continue;
> > }
> > if (connector->tile_h_loc < h_idx)
> > @@ -438,14 +440,15 @@ static bool drm_client_target_preferred(struct
> > drm_device *dev,
> > drm_client_get_tile_offsets(dev, connectors,
> > connector_count, modes, offsets, i,
> > connector->tile_h_loc,
> > connector->tile_v_loc);
> > }
> > - drm_dbg_kms(dev, "looking for cmdline mode on connector %d\n",
> > - connector->base.id);
> > + drm_dbg_kms(dev, "looking for cmdline mode on
> > [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> >
> > /* got for command line mode first */
> > modes[i] = drm_connector_pick_cmdline_mode(connector);
> > if (!modes[i]) {
> > - drm_dbg_kms(dev, "looking for preferred mode on
> > connector %d %d\n",
> > - connector->base.id, connector->tile_group ?
> > connector->tile_group->id : 0);
> > + drm_dbg_kms(dev, "looking for preferred mode on
> > [CONNECTOR:%d:%s] (tile group: %d)\n",
> > + connector->base.id, connector->name,
> > + connector->tile_group ?
> > connector->tile_group->id : 0);
> > modes[i] = drm_connector_preferred_mode(connector,
> > width, height);
> > }
> > /* No preferred modes, pick one off the list */
> > @@ -465,8 +468,8 @@ static bool drm_client_target_preferred(struct
> > drm_device *dev,
> > (connector->tile_h_loc == 0 &&
> > connector->tile_v
Re: [PATCH 11/12] drm/client: Streamline mode selection debugs
On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > Get rid of all the redundant debugs and just wait until the end
> > to print which mode (and of which type) we picked.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_client_modeset.c | 65 +---
> > 1 file changed, 31 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > b/drivers/gpu/drm/drm_client_modeset.c
> > index 415d1799337b..ad88c11037d8 100644
> > --- a/drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -408,6 +408,8 @@ static bool drm_client_target_preferred(struct
> > drm_device *dev,
> >
> > retry:
> > for (i = 0; i < connector_count; i++) {
> > + const char *mode_type;
> > +
> > connector = connectors[i];
> >
> > if (conn_configured & BIT_ULL(i))
> > @@ -440,20 +442,20 @@ static bool drm_client_target_preferred(struct
> > drm_device *dev,
> > drm_client_get_tile_offsets(dev, connectors,
> > connector_count, modes, offsets, i,
> > connector->tile_h_loc,
> > connector->tile_v_loc);
> > }
> > - drm_dbg_kms(dev, "looking for cmdline mode on
> > [CONNECTOR:%d:%s]\n",
> > - connector->base.id, connector->name);
> >
> > - /* got for command line mode first */
> > + mode_type = "cmdline";
> > modes[i] = drm_connector_pick_cmdline_mode(connector);
> > +
> > if (!modes[i]) {
> > - drm_dbg_kms(dev, "looking for preferred mode on
> > [CONNECTOR:%d:%s] (tile group: %d)\n",
> > - connector->base.id, connector->name,
> > - connector->tile_group ?
> > connector->tile_group->id : 0);
> > + mode_type = "preferred";
> > modes[i] = drm_connector_preferred_mode(connector,
> > width, height);
> > }
> > - /* No preferred modes, pick one off the list */
> > - if (!modes[i])
> > +
> > + if (!modes[i]) {
> > + mode_type = "first";
> > modes[i] = drm_connector_first_mode(connector);
> > + }
> > +
> > /*
> > * In case of tiled mode if all tiles not present fallback to
> > * first available non tiled mode.
> > @@ -468,16 +470,20 @@ static bool drm_client_target_preferred(struct
> > drm_device *dev,
> > (connector->tile_h_loc == 0 &&
> > connector->tile_v_loc == 0 &&
> > !drm_connector_get_tiled_mode(connector))) {
> > - drm_dbg_kms(dev, "Falling back to non tiled
> > mode on [CONNECTOR:%d:%s]\n",
> > - connector->base.id,
> > connector->name);
> > + mode_type = "non tiled";
> > modes[i] =
> > drm_connector_fallback_non_tiled_mode(connector);
> > } else {
> > + mode_type = "tiled";
> > modes[i] =
> > drm_connector_get_tiled_mode(connector);
> > }
> > }
> >
> > - drm_dbg_kms(dev, "found mode %s\n",
> > - modes[i] ? modes[i]->name : "none");
> > + if (!modes[i])
> > + mode_type = "no";
> > +
> > + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] found %s mode: %s\n",
> > + connector->base.id, connector->name,
> > + mode_type, modes[i] ? modes[i]->name : "none");
>
> Instead of tracking the whole mode_type thing, maybe just do
>
> if (!modes[i])
> drm_dbg_kms(dev, "[CONNECTOR:%d:%s] found mode: " DRM_MODE_FMT,
> DRM_MODE_ARG(modes[i]) );
>
> to print the full mode.
The point of the mode_type is to indicate how we derived
that mode. Printing the full modeline doesn't help with that.
--
Ville Syrjälä
Intel
Re: [PATCH 04/12] drm/client: Add a FIXME around crtc->mode usage
On Fri, Apr 05, 2024 at 06:32:46AM +0300, Dmitry Baryshkov wrote:
> On Thu, Apr 04, 2024 at 11:33:28PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > crtc->mode is legacy junk and shouldn't really be used with
> > atomic drivers.
> >
> > Most (all?) atomic drivers do end up still calling
> > drm_atomic_helper_update_legacy_modeset_state() at some
> > point, so crtc->mode does still get populated, and this
> > does work for now. But eventually would be nice to eliminate
> > all the legacy stuff from atomic drivers.
> >
> > Switching to crtc->state->mode would require some bigger
> > changes however, as we currently drop the crtc->mutex
> > before we're done using the mode. So leave the junk in
> > for now and just add a FIXME to remind us that this
> > needs fixing.
>
>
> What about using allocated duplicate modes to fill modes[] array? This
> requires additional allocations, but it will solve most if not all modes
> lifetime issues.
I think there are two obvious solutions:
1. drm_mode_duplicate() as you suggest
upside: existing 'modes[i] != NULL' checks work as is
downside: introduces more error paths due to potential kmalloc() fails
2. Make modes[] and array of structs rather than pointers
up/downsides: the opposite of option 1
So neither is a trivial search and replace job.
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_client_modeset.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > b/drivers/gpu/drm/drm_client_modeset.c
> > index 2b7d0be04911..8ef03608b424 100644
> > --- a/drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -699,6 +699,10 @@ static bool drm_client_firmware_config(struct
> > drm_client_dev *client,
> > *
> > * This is crtc->mode and not crtc->state->mode for the
> > * fastboot check to work correctly.
> > +*
> > +* FIXME using legacy crtc->mode with atomic drivers
> > +* is dodgy. Switch to crtc->state->mode, after taking
> > +* care of the resulting locking/lifetime issues.
> > */
> > DRM_DEBUG_KMS("looking for current mode on connector
> > %s\n",
> > connector->name);
> > --
> > 2.43.2
> >
>
> --
> With best wishes
> Dmitry
--
Ville Syrjälä
Intel
Re: [PATCH 01/12] drm/client: Fully protect modes[] with dev->mode_config.mutex
On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The modes[] array contains pointers to modes on the connectors'
> > mode lists, which are protected by dev->mode_config.mutex.
> > Thus we need to extend modes[] the same protection or by the
> > time we use it the elements may already be pointing to
> > freed/reused memory.
> >
> > Cc: sta...@vger.kernel.org
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Dmitry Baryshkov
>
> I tried looking for the proper Fixes tag, but it looks like it might be
> something like 386516744ba4 ("drm/fb: fix fbdev object model + cleanup
> properly.")
The history is rather messy. I think it was originally completely
lockless and broken, and got fixed piecemeal later in these:
commit 7394371d8569 ("drm: Take lock around probes for
drm_fb_helper_hotplug_event")
commit 966a6a13c666 ("drm: Hold mode_config.lock to prevent hotplug whilst
setting up crtcs")
commit e13a05831050 ("drm/fb-helper: Stop using mode_config.mutex for
internals")
looks to me like where the race might have been re-introduced.
But didn't do a thorough analysis so not 100% sure. It's all
rather ancient history by now so a Fixes tag doesn't seem all
that useful anyway.
--
Ville Syrjälä
Intel
Re: [PATCH 1/6] drm/modes: add drm_mode_print() to dump mode in drm_printer
On Fri, Apr 05, 2024 at 10:45:42AM +0200, Thomas Zimmermann wrote: > Hi > > Am 07.03.24 um 21:39 schrieb Jani Nikula: > > Add a printer based function for dumping the modeline, so it's not > > limited to KMS debug. > > > > Note: The printed output intentionally does not have the "Modeline" > > prefix. Prefix, if any, is for the caller to decide when initializing > > drm_printer. > > > > Signed-off-by: Jani Nikula > > --- > > drivers/gpu/drm/drm_modes.c | 13 + > > include/drm/drm_modes.h | 2 ++ > > 2 files changed, 15 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > > index c4f88c3a93b7..711750ab57c7 100644 > > --- a/drivers/gpu/drm/drm_modes.c > > +++ b/drivers/gpu/drm/drm_modes.c > > @@ -49,6 +49,19 @@ > > > > #include "drm_crtc_internal.h" > > > > +/** > > + * drm_mode_print - print a mode to drm printer > > + * @p: drm printer > > + * @mode: mode to print > > + * > > + * Write @mode description to struct drm_printer @p. > > + */ > > +void drm_mode_print(struct drm_printer *p, const struct drm_display_mode > > *mode) > > Could this be a printf function with a trailing format string as final > argument? The printed mode could then be part of another string instead > of just at the end of it. All this seems pretty much redundant. We already have DRM_MODE_FMT/ARGS so people can include the mode in any kind of format string they want. I would just nuke drm_mode_print() and all its ilk and let people format things themselves. -- Ville Syrjälä Intel
Re: [PATCH v0 02/14] drm/amdgpu,drm/radeon: Make I2C terminology more inclusive
On Fri, Mar 29, 2024 at 06:38:10PM +0100, Andi Shyti wrote: > Hi, > > On Fri, Mar 29, 2024 at 10:28:14AM -0700, Easwar Hariharan wrote: > > On 3/29/2024 10:16 AM, Andi Shyti wrote: > > > Hi Easwar, > > > > > > On Fri, Mar 29, 2024 at 05:00:26PM +, Easwar Hariharan wrote: > > >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > > > > > > I don't understand why we forget that i3c is 1.1.1 :-) > > > > That's because it's a copy-paste error from Wolfram's cover letter. :) I'll > > update > > next go-around. > > not a binding comment, though. Just for completeness, because we > are giving the version to the i2c and smbus, but not i3c. > > > >> with more appropriate terms. Inspired by and following on to Wolfram's > > >> series to fix drivers/i2c/[1], fix the terminology for users of > > >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > > >> in the specification. > > > > > > The specification talks about: > > > > > > - master -> controller > > > - slave -> target (and not client) > > > > > > But both you and Wolfram have used client. I'd like to reach > > > some more consistency here. > > > > I had the impression that remote targets (i.e external to the device) were > > to be called clients, > > e.g. the QSFP FRUs in drivers/infiniband, and internal ones targets. > > I chose the terminology according to that understanding, but now I can't > > find where I got that > > information. > > The word "client" does not even appear in the documentation (only > one instance in the i3c document), so that the change is not > related to the document as stated in the commit log. Unless, of > course, I am missing something. > > I'm OK with choosing a "customized" naming, but we need to reach > an agreement. > > I raised the same question to Wolfram. I don't know where that discussion happened, but my opinion is NAK to "client". Life is already confusing enough with these renames, so let's not make it even more confusing by inventing new names nowhere to be found in the spec. And let's especially not invent names that don't even fit the purpose. "Client" makes me think of "client/server" or some real world analogy. Neither of which seem to have any resemblence to how the term would be used for i2c. -- Ville Syrjälä Intel
Re: [PATCH] drm/i915/hwmon: Fix potential UAF on driver unbind
> + return 0;
> +
> switch (type) {
> case hwmon_energy:
> return hwm_energy_is_visible(ddat, attr);
> @@ -700,6 +712,9 @@ hwm_gt_read(struct device *dev, enum hwmon_sensor_types
> type, u32 attr,
> {
> struct hwm_drvdata *ddat = dev_get_drvdata(dev);
>
> + if (!ddat->uncore)
> + return -ENXIO;
> +
> switch (type) {
> case hwmon_energy:
> return hwm_energy_read(ddat, attr, val);
> @@ -850,5 +865,14 @@ void i915_hwmon_register(struct drm_i915_private *i915)
>
> void i915_hwmon_unregister(struct drm_i915_private *i915)
> {
> + struct i915_hwmon *hwmon = i915->hwmon;
> + struct intel_gt *gt;
> + int i;
> +
> + for_each_gt(gt, i915, i)
> + fetch_and_zero(>ddat_gt[i].uncore);
> +
> + fetch_and_zero(>ddat.uncore);
> +
> fetch_and_zero(>hwmon);
> }
> --
> 2.43.0
--
Ville Syrjälä
Intel
Re: [PATCH v3 0/2] drm: Add plane SIZE_HINTS property
On Mon, Mar 18, 2024 at 10:44:06PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Final final version I hope. Mainly for CI to test against the > new IGTs. > > Real userspace implementation: > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165 > > > IGT: > https://patchwork.freedesktop.org/series/131199/ CI said the IGT was correctly skipping without the kernel patches, and passed on all i915 supported machines with the kernel patches in place. So looks like we're all good to merge this, as soon as I get someone to review thew i915 patch... PS. I forgot to cc dri-devel with this series, but bounced the whole thing there now. > > Changes from v2: > - Limit to cursor planes only (Simon) > > Test-with: 20240315191505.27620-1-ville.syrj...@linux.intel.com > Cc: Simon Ser > Cc: Jonas Ådahl > Cc: Daniel Stone > Cc: Sameer Lattannavar > Cc: Sebastian Wick > Cc: Harry Wentland > 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 | 56 + > 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 | 11 > 6 files changed, 107 insertions(+) > > -- > 2.43.2 -- Ville Syrjälä Intel
Re: [PATCH v9 20/27] drm/connector: hdmi: Add Infoframes generation
On Mon, Mar 18, 2024 at 02:49:47PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Mar 15, 2024 at 10:22:05AM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 11, 2024 at 03:49:48PM +0100, Maxime Ripard wrote:
> > > Infoframes in KMS is usually handled by a bunch of low-level helpers
> > > that require quite some boilerplate for drivers. This leads to
> > > discrepancies with how drivers generate them, and which are actually
> > > sent.
> > >
> > > Now that we have everything needed to generate them in the HDMI
> > > connector state, we can generate them in our common logic so that
> > > drivers can simply reuse what we precomputed.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/Kconfig| 1 +
> > > drivers/gpu/drm/drm_atomic_state_helper.c | 323
> > > +
> > > drivers/gpu/drm/drm_connector.c| 14 +
> > > .../gpu/drm/tests/drm_atomic_state_helper_test.c | 1 +
> > > drivers/gpu/drm/tests/drm_connector_test.c | 12 +
> > > include/drm/drm_atomic_state_helper.h | 8 +
> > > include/drm/drm_connector.h| 133 +
> > > 7 files changed, 492 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index 872edb47bb53..ad9c467e20ce 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -97,10 +97,11 @@ config DRM_KUNIT_TEST
> > > If in doubt, say "N".
> > >
> > > config DRM_KMS_HELPER
> > > tristate
> > > depends on DRM
> > > + select DRM_DISPLAY_HDMI_HELPER
> > > help
> > > CRTC helpers for KMS drivers.
> > >
> > > config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
> > > bool "Enable refcount backtrace history in the DP MST helpers"
> > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > index e66272c0d006..2bf53666fc9d 100644
> > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > @@ -36,10 +36,12 @@
> > > #include
> > > #include
> > > #include
> > > #include
> > >
> > > +#include
> > > +
> > > #include
> > > #include
> > >
> > > /**
> > > * DOC: atomic state reset and initialization
> > > @@ -912,10 +914,143 @@ hdmi_compute_config(const struct drm_connector
> > > *connector,
> > > }
> > >
> > > return -EINVAL;
> > > }
> > >
> > > +static int hdmi_generate_avi_infoframe(const struct drm_connector
> > > *connector,
> > > +struct drm_connector_state *state)
> > > +{
> > > + const struct drm_display_mode *mode =
> > > + connector_state_get_mode(state);
> > > + struct drm_connector_hdmi_infoframe *infoframe =
> > > + >hdmi.infoframes.avi;
> > > + struct hdmi_avi_infoframe *frame =
> > > + >data.avi;
> > > + bool is_full_range = state->hdmi.is_full_range;
> > > + enum hdmi_quantization_range rgb_quant_range =
> > > + is_full_range ? HDMI_QUANTIZATION_RANGE_FULL :
> > > HDMI_QUANTIZATION_RANGE_LIMITED;
> > > + int ret;
> > > +
> > > + ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector, mode);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + frame->colorspace = state->hdmi.output_format;
> > > +
> > > + drm_hdmi_avi_infoframe_quant_range(frame, connector, mode,
> > > rgb_quant_range);
> >
> > drm_hdmi_avi_infoframe_quant_range() doesn't handle YCbCr currently.
>
> I guess it's not really a problem anymore if we drop YUV422 selection,
> but I'll add a comment.
>
> > > + drm_hdmi_avi_infoframe_colorimetry(frame, state);
> > > + drm_hdmi_avi_infoframe_bars(frame, state);
> > > +
> > > + infoframe->set = true;
> > > +
> > > + return 0;
> > > +}
> > > +
> >
> > > +
> > > +#define UPDATE_INFOFRAME(c, os, ns, i) \
> > > + write_or_clear_infoframe(c, \
> > > + &(c)->hdmi.infoframes.i, \
&g
Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
On Mon, Mar 18, 2024 at 12:52:10PM +0200, Jani Nikula wrote:
> On Mon, 18 Mar 2024, Neil Armstrong wrote:
> > Hi,
> >
> > On Thu, 11 Jan 2024 13:38:04 +0100, Luca Weiss wrote:
> >> Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
> >> bridge/panel.o to drm_kms_helper object, we need to select
> >> DRM_KMS_HELPER to make sure the file is actually getting built.
> >>
> >> Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
> >> be properly available:
> >>
> >> [...]
> >
> > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git
> > (drm-misc-fixes)
> >
> > [1/1] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
> >
> > https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/e3f18b0dd1db242791afbc3bd173026163ce0ccc
>
> With my kernel config, e3f18b0dd1db ("drm/bridge: Select DRM_KMS_HELPER
> for DRM_PANEL_BRIDGE") leads to:
>
> WARNING: unmet direct dependencies detected for DRM_KMS_HELPER
> Depends on [m]: HAS_IOMEM [=y] && DRM [=m]
...
All the defconfigs in drm-rerere also seem to fail here.
Neil, are you using some weird .config, or did you not actually
build test this before pushing?
PS. the drm-rerere defconfigs seem pretty outdated (eg. missing
tons of panel drivers). Would be good if someone could update
those to provide better coverage
--
Ville Syrjälä
Intel
Re: [PATCH v9 14/27] drm/connector: hdmi: Compute bpc and format automatically
On Mon, Mar 18, 2024 at 01:05:22PM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> Thanks for your review !
>
> On Fri, Mar 15, 2024 at 10:05:16AM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 11, 2024 at 03:49:42PM +0100, Maxime Ripard wrote:
> > > +static bool
> > > +sink_supports_format_bpc(const struct drm_connector *connector,
> > > + const struct drm_display_info *info,
> > > + const struct drm_display_mode *mode,
> > > + unsigned int format, unsigned int bpc)
> > > +{
> > > + struct drm_device *dev = connector->dev;
> > > + u8 vic = drm_match_cea_mode(mode);
> > > +
> > > + if (vic == 1 && bpc != 8) {
> > > + drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc);
> >
> > Use of drm_dbg() for kms stuff is surprising.
> >
> > > + return false;
> > > + }
> >
> > I don't think we have this in i915. My original impression was that you
> > can use higher color depth if you can determine the sink capabilities,
> > but all sinks are required to accept 640x480@8bpc as a fallback.
> >
> > but CTA-861-H says:
> > "5.4 Color Coding & Quantization
> > Component Depth: The coding shall be N-bit, where N = 8, 10, 12, or 16
> > bits/component — except in the case of the default 640x480 Video Timing 1,
> > where the value of N shall be 8."
> >
> > So that does seem to imply that you're supposed to use exactly 8bpc.
> > Though the word "default" in there is confusing. Are they specifically
> > using that to indicate that this is about the fallback behaviour, or
> > is it just indicating that it is a "default mode that always has to
> > be supported". Dunno. I guess no real harm in forcing 8bpc for 640x480
> > since no one is likely to use that for any high fidelity stuff.
>
> My understanding was that CTA-861 mandates that 640x480@60Hz is
> supported, and mentions it being the default timing on a few occurences,
> like in section 4 - Video Formats and Waveform Timings that states "This
> section describes the default IT 640x480 Video Timing as well as all of
> the standard CE Video Timings.", or Section 6.2 - Describing Video
> Formats in EDID "The 640x480@60Hz flag, in the Established Timings area,
> shall always be set, since the 640x480p format is a mandatory default
> timing."
>
> So my understanding is that default here applies to the timing itself,
> and not the bpc, and is thus the second interpretation you suggested.
>
> I'll add a comment to make it clearer.
>
> > > +static int
> > > +hdmi_compute_format(const struct drm_connector *connector,
> > > + struct drm_connector_state *state,
> > > + const struct drm_display_mode *mode,
> > > + unsigned int bpc)
> > > +{
> > > + struct drm_device *dev = connector->dev;
> > > +
> > > + if (hdmi_try_format_bpc(connector, state, mode, bpc,
> > > HDMI_COLORSPACE_RGB)) {
> > > + state->hdmi.output_format = HDMI_COLORSPACE_RGB;
> > > + return 0;
> > > + }
> > > +
> > > + if (hdmi_try_format_bpc(connector, state, mode, bpc,
> > > HDMI_COLORSPACE_YUV422)) {
> > > + state->hdmi.output_format = HDMI_COLORSPACE_YUV422;
> > > + return 0;
> > > + }
> >
> > Looks like you're preferring YCbCr 4:2:2 over RGB 8bpc. Not sure
> > if that's a good tradeoff to make.
>
> Yeah, indeed. I guess it's a judgement call on whether we prioritise
> lowering the bpc over selecting YUV422, but I guess I can try all
> available RGB bpc before falling back to YUV422.
>
> > In i915 we don't currently expose 4:2:2 at all because it doesn't
> > help in getting a working display, and we have no uapi for the
> > user to force it if they really want 4:2:2 over RGB.
>
> I guess if the priority is given to lowering bpc, then it indeed doesn't
> make sense to support YUV422, since the limiting factor is likely to be
> the TMDS char rate and YUV422 12 bpc is equivalent to RGB 8bpc there.
>
> dw-hdmi on the other hand will always put YUV422 and YUV444 before RGB
> for a given bpc, which is weird to me:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2696
>
> What is even weirder to me is that YUV422 is explicitly stated to be
> 12bpc only, so there's some invalid configurations there (8 and 10 bpc).
>
> And given that it's order by decreasing order of preference,
Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On Wed, Feb 28, 2024 at 10:12:28AM +, Simon Ser wrote: > On Tuesday, February 27th, 2024 at 20:35, Ville Syrjala > wrote: > > > 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. > > Typo: strategy > > > 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. > > > > Userspace consumer in the form of mutter seems ready: > > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165 > > Do we need an IGT as well to merge this new uAPI? At least for i915 the current igts already cover a superset of what the property reports. But I guess we could add another test that explicitly tests the sizes reported by the hint as well, if not already covered by other tests. > > > v2: Try to add some docs > > v3: Specify that value 0 is reserved for future use (basic idea from Jonas) > > Drop the note about typical hardware (Pekka) > > v4: Update the docs to indicate the list is "in order of preference" > > Add a a link to the mutter MR > > > > Cc: Simon Ser > > Cc: Jonas Ådahl > > Cc: Daniel Stone > > Cc: Sameer Lattannavar > > Cc: Sebastian Wick > > Acked-by: Harry Wentland > > Acked-by: Pekka Paalanen > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_mode_config.c | 7 + > > drivers/gpu/drm/drm_plane.c | 52 +++ > > include/drm/drm_mode_config.h | 5 +++ > > include/drm/drm_plane.h | 4 +++ > > include/uapi/drm/drm_mode.h | 11 +++ > > 5 files changed, 79 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > b/drivers/gpu/drm/drm_mode_config.c > > index 48fd2d67f352..568972258222 100644 > > --- a/drivers/gpu/drm/drm_mode_config.c > > +++ b/drivers/gpu/drm/drm_mode_config.c > > @@ -372,6 +372,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 672c655c7a8e..4135ce16e608 100644 > > --- a/drivers/gpu/drm/drm_plane.c > > +++ b/drivers/gpu/drm/drm_plane.c > > @@ -140,6 +140,25 @@ > > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have > > been > > * various bugs in this area with inconsistencies between the > > capability > > * flag and per-plane properties. > > + * > > + * SIZE_HINTS: > > + * Blob property which contains the set of recommended plane size > > + * which can used for simple "cursor like" use cases (eg. no scaling). > > + * Using these hints frees userspace from extensive probing of > > + * supported plane sizes through atomic/setcursor ioctls. > > + * > > + * The blob contains an array of struct drm_plane_size_hint, in > > + * order of preference. For optimal usage userspace should
Re: [PATCH v9 20/27] drm/connector: hdmi: Add Infoframes generation
onnector Control Functions
>*/
> const struct drm_connector_hdmi_funcs *funcs;
> +
> + /**
> + * @infoframes: Current Infoframes output by the connector
> + */
> + struct {
> + /**
> + * @lock: Mutex protecting against concurrent access to
> + * the infoframes, most notably between KMS and ALSA.
> + */
> + struct mutex lock;
> +
> + /**
> + * @audio: Current Audio Infoframes structure. Protected
> + * by @lock.
> + */
> + struct drm_connector_hdmi_infoframe audio;
> +
> + /**
> + * @avi: Current AVI Infoframes structure. Protected by
> + * @lock.
> + */
> + struct drm_connector_hdmi_infoframe avi;
> +
> + /**
> + * @hdr_drm: Current DRM (Dynamic Range and Mastering)
> + * Infoframes structure. Protected by @lock.
> + */
> + struct drm_connector_hdmi_infoframe hdr_drm;
> +
> + /**
> + * @spd: Current SPD Infoframes structure. Protected by
> + * @lock.
> + */
> + struct drm_connector_hdmi_infoframe spd;
> +
> + /**
> + * @vendor: Current HDMI Vendor Infoframes structure.
> + * Protected by @lock.
> + */
> + struct drm_connector_hdmi_infoframe hdmi;
> + } infoframes;
> } hdmi;
What's the deal with this bloat? These are already tracked in the
connector's state so this looks entirely redundant.
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
>
> @@ -2015,10 +2147,11 @@ int drmm_connector_init(struct drm_device *dev,
> const struct drm_connector_funcs *funcs,
> int connector_type,
> struct i2c_adapter *ddc);
> int drmm_connector_hdmi_init(struct drm_device *dev,
>struct drm_connector *connector,
> + const char *vendor, const char *product,
>const struct drm_connector_funcs *funcs,
>const struct drm_connector_hdmi_funcs *hdmi_funcs,
>int connector_type,
>struct i2c_adapter *ddc,
>unsigned long supported_formats,
>
> --
> 2.43.2
--
Ville Syrjälä
Intel
Re: [PATCH v9 14/27] drm/connector: hdmi: Compute bpc and format automatically
ew_conn_state->max_requested_bpc); > > ret = drm_atomic_check_only(state); > KUNIT_ASSERT_EQ(test, ret, 0); > > old_conn_state = drm_atomic_get_old_connector_state(state, conn); > @@ -318,14 +320,19 @@ static void > drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test) > priv = drm_atomic_helper_connector_hdmi_init(test, >BIT(HDMI_COLORSPACE_RGB), >10); > KUNIT_ASSERT_NOT_NULL(test, priv); > > + conn = >connector; > + ret = set_connector_edid(test, conn, > + test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz, > + > ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz)); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > ctx = drm_kunit_helper_acquire_ctx_alloc(test); > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx); > > - conn = >connector; > preferred = find_preferred_mode(conn); > KUNIT_ASSERT_NOT_NULL(test, preferred); > > drm = >drm; > crtc = priv->crtc; > @@ -668,11 +675,11 @@ static void drm_test_check_format_value(struct kunit > *test) >8); > KUNIT_ASSERT_NOT_NULL(test, priv); > > conn = >connector; > conn_state = conn->state; > - KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, > HDMI_COLORSPACE_RGB); > + KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, 0); > } > > /* > * Test that the value of the output format property out of reset is set > * to 0, and will be computed at atomic_check time. > > -- > 2.43.2 -- Ville Syrjälä Intel
Re: [PATCH] drm/udl: Add ARGB8888 as a format
On Wed, Mar 06, 2024 at 07:37:16AM -0800, Rob Clark wrote:
> On Wed, Mar 6, 2024 at 7:06 AM Ville Syrjälä
> wrote:
> >
> > On Wed, Mar 06, 2024 at 06:49:15AM -0800, Rob Clark wrote:
> > > On Wed, Mar 6, 2024 at 4:18 AM Thomas Zimmermann
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > sorry that I did not see the patch before.
> > > >
> > > > Am 27.02.24 um 23:19 schrieb Douglas Anderson:
> > > > > Even though the UDL driver converts to RGB565 internally (see
> > > > > pixel32_to_be16() in udl_transfer.c), it advertises XRGB for
> > > > > compatibility. Let's add ARGB to that list.
> > > >
> > > > We had a heated discussion about the emulation of color formats. It was
> > > > decided that XRGB is the only format to support; and that's only
> > > > because legacy userspace sometimes expects it. Adding other formats to
> > > > the list should not be done easily.
> > >
> > > OTOH it is fixing a kernel change that broke userspace
> > >
> > > > >
> > > > > This makes UDL devices work on ChromeOS again after commit
> > > > > c91acda3a380 ("drm/gem: Check for valid formats"). Prior to that
> > > > > commit things were "working" because we'd silently treat the ARGB
> > > > > that ChromeOS wanted as XRGB.
> > > >
> > > > This problem has been caused by userspace. Why can it not be fixed
> > > > there?
> > > >
> > > > And udl is just one driver. Any other driver without ARGB, such as
> > > > simpledrm or ofdrm, would be affected. Do these work?
> > >
> > > Probably any driver where ARGB is equivalent to XRGB (ie.
> > > single primary plane, etc) should advertise both.
> >
> > To me that seemes likely to trick userspace developers into
> > assuming that ARGB is always available, and then when they
> > finally try on hardware that doesn't have ARGB it'll just
> > fail miserably.
>
> I think that ship has sailed already, at least for any drivers that
> previously silently accepted ARGB
Perhaps. Although I don't actually understand what kind of weird
userspace people are running if it somehow expects ARGB to be there,
but only for some specific kms drivers. Is said userspace really
somehow checking which kms driver is present and then just ignoring
the pixel format list exposed by the driver? Or is it just some
super hw specific thing where they can just assume a specific kms
driver?
Anyways, adding ARGB to even more drivers seems like a terrible
idea to me.
--
Ville Syrjälä
Intel
Re: [PATCH] drm/udl: Add ARGB8888 as a format
On Wed, Mar 06, 2024 at 06:49:15AM -0800, Rob Clark wrote:
> On Wed, Mar 6, 2024 at 4:18 AM Thomas Zimmermann wrote:
> >
> > Hi,
> >
> > sorry that I did not see the patch before.
> >
> > Am 27.02.24 um 23:19 schrieb Douglas Anderson:
> > > Even though the UDL driver converts to RGB565 internally (see
> > > pixel32_to_be16() in udl_transfer.c), it advertises XRGB for
> > > compatibility. Let's add ARGB to that list.
> >
> > We had a heated discussion about the emulation of color formats. It was
> > decided that XRGB is the only format to support; and that's only
> > because legacy userspace sometimes expects it. Adding other formats to
> > the list should not be done easily.
>
> OTOH it is fixing a kernel change that broke userspace
>
> > >
> > > This makes UDL devices work on ChromeOS again after commit
> > > c91acda3a380 ("drm/gem: Check for valid formats"). Prior to that
> > > commit things were "working" because we'd silently treat the ARGB
> > > that ChromeOS wanted as XRGB.
> >
> > This problem has been caused by userspace. Why can it not be fixed there?
> >
> > And udl is just one driver. Any other driver without ARGB, such as
> > simpledrm or ofdrm, would be affected. Do these work?
>
> Probably any driver where ARGB is equivalent to XRGB (ie.
> single primary plane, etc) should advertise both.
To me that seemes likely to trick userspace developers into
assuming that ARGB is always available, and then when they
finally try on hardware that doesn't have ARGB it'll just
fail miserably.
--
Ville Syrjälä
Intel
Re: [PATCH v2] drm/i915/overlay: Remove redundant drm_rect_visible() use
On Sat, Mar 25, 2023 at 02:27:19PM -0300, Arthur Grillo wrote: > The drm_rect_intersect() already returns if the intersection is visible > or not, so the use of drm_rect_visible() is duplicate. > > Signed-off-by: Arthur Grillo Sorry, looks like I completely missed this. Now push the drm-intel-next. Thanks. > --- > v1->v2: > https://lore.kernel.org/all/20230324142533.6357-1-arthurgri...@riseup.net/ > - Split the if condition. > --- > drivers/gpu/drm/i915/display/intel_overlay.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c > b/drivers/gpu/drm/i915/display/intel_overlay.c > index c12bdca8da9b..d55153587cae 100644 > --- a/drivers/gpu/drm/i915/display/intel_overlay.c > +++ b/drivers/gpu/drm/i915/display/intel_overlay.c > @@ -966,10 +966,11 @@ static int check_overlay_dst(struct intel_overlay > *overlay, > rec->dst_width, rec->dst_height); > > clipped = req; > - drm_rect_intersect(, _state->pipe_src); > > - if (!drm_rect_visible() || > - !drm_rect_equals(, )) > + if (!drm_rect_intersect(, _state->pipe_src)) > + return -EINVAL; > + > + if (!drm_rect_equals(, )) > return -EINVAL; > > return 0; > -- > 2.39.2 -- Ville Syrjälä Intel
Re: [PATCH] drm/i915: Remove unneeded double drm_rect_visible call in check_overlay_dst
On Fri, Mar 01, 2024 at 09:56:41PM +0300, Nikita Kiryushin wrote: > On 2/29/24 15:30, Ville Syrjälä wrote: > > I prefer the current way where we have no side effects in > > the if statement. > > > > This seem like a valid concern from readability and maintainability > standpoint. My patch was aimed mostly at performance and maintainability > using tools: some more pedantic analyzers are sensitive to non-checked > return values (as of now, drm_rect_intersect is ignored). > > Would it be a better idea to make an update to the patch with second > drm_rect_visible call changed to an appropriately named state flag set > with drm_rect_intersect result? I was thinking of maybe removing that drm_rect_visible() from drm_rect_intersect() entirely, but looks like it's used fairly extensively, so would require a bunch of work. But now that I though about this I recalled that there was an earlier patch trying to do exactly what you suggested in this patch. And looks like there was a second version posted which I completely missed: https://patchwork.freedesktop.org/series/115605/ While that does still have drm_rect_intersect() with its side effects inside the if() I don't find it quite as objectionable since it's the only thing in there. So it's a bit more obvious what is happening. I've gone and merged that one. Thanks for the patch regardless. At least I reminded me to look at the earlier attempt ;) > > BTW, the original patch somehow got mangled while it made its way to the > patchwork: source list line in patch got broken, which permits the patch > from being applied (the original version did not have that line break). > Any ideas how to prevent this happening with the second version of patch > (in case the idea is viable)? -- Ville Syrjälä Intel
Re: [PATCH] drm/dp: Fix documentation of DP tunnel functions
On Wed, Feb 28, 2024 at 06:46:36PM +0200, Imre Deak wrote:
> Fix the documentation issues below, also reported by 'make htmldocs':
>
> drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or
> struct member 'tunnel' not described in 'drm_dp_tunnel_put'
> drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or
> struct member 'tracker' not described in 'drm_dp_tunnel_put'
> drivers/gpu/drm/display/drm_dp_tunnel.c:1185: warning: expecting prototype
> for drm_dp_tunnel_atomic_get_allocated_bw(). Prototype was for
> drm_dp_tunnel_get_allocated_bw() instead
> drivers/gpu/drm/display/drm_dp_tunnel.c:1903: warning: Function parameter or
> struct member 'max_group_count' not described in 'drm_dp_tunnel_mgr_create'
>
> Fixes: 295654f7e554 ("drm/dp: Add support for DP tunneling")
> Reported-by: kernel test robot
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/display/drm_dp_tunnel.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_tunnel.c
> b/drivers/gpu/drm/display/drm_dp_tunnel.c
> index 120e0de674c19..017f1d4c63415 100644
> --- a/drivers/gpu/drm/display/drm_dp_tunnel.c
> +++ b/drivers/gpu/drm/display/drm_dp_tunnel.c
> @@ -436,8 +436,8 @@ EXPORT_SYMBOL(drm_dp_tunnel_get);
>
> /**
> * drm_dp_tunnel_put - Put a reference for a DP tunnel
> - * @tunnel - Tunnel object
> - * @tracker - Debug tracker for the reference
> + * @tunnel: Tunnel object
> + * @tracker: Debug tracker for the reference
> *
> * Put a reference for @tunnel along with its debug *@tracker, which
> * was obtained with drm_dp_tunnel_get().
> @@ -1170,7 +1170,7 @@ int drm_dp_tunnel_alloc_bw(struct drm_dp_tunnel
> *tunnel, int bw)
> EXPORT_SYMBOL(drm_dp_tunnel_alloc_bw);
>
> /**
> - * drm_dp_tunnel_atomic_get_allocated_bw - Get the BW allocated for a DP
> tunnel
> + * drm_dp_tunnel_get_allocated_bw - Get the BW allocated for a DP tunnel
> * @tunnel: Tunnel object
> *
> * Get the current BW allocated for @tunnel. After the tunnel is created /
> @@ -1892,6 +1892,7 @@ static void destroy_mgr(struct drm_dp_tunnel_mgr *mgr)
> /**
> * drm_dp_tunnel_mgr_create - Create a DP tunnel manager
> * @dev: DRM device object
> + * @max_group_count: Maximum number of tunnel groups
> *
> * Creates a DP tunnel manager for @dev.
> *
> --
> 2.43.3
--
Ville Syrjälä
Intel
Re: [PATCH] drm/i915: Remove unneeded double drm_rect_visible call in check_overlay_dst
On Wed, Feb 28, 2024 at 09:32:47PM +0300, Nikita Kiryushin wrote:
>
> check_overlay_dst for clipped is called 2 times: in drm_rect_intersect
> and than directly. Change second call for check of drm_rect_intersect
> result to save some time (in locked code section).
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: 8d8b2dd3995f ("drm/i915: Make the PIPESRC rect relative to the
> entire bigjoiner area")
> Signed-off-by: Nikita Kiryushin
> ---
> drivers/gpu/drm/i915/display/intel_overlay.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index 2b1392d5a902..1cda1c163a92 100644
> --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> @@ -972,9 +972,8 @@ static int check_overlay_dst(struct intel_overlay
> *overlay,
> rec->dst_width, rec->dst_height);
> clipped = req;
> - drm_rect_intersect(, _state->pipe_src);
> - if (!drm_rect_visible() ||
> + if (!drm_rect_intersect(, _state->pipe_src) ||
I prefer the current way where we have no side effects in
the if statement.
> !drm_rect_equals(, ))
> return -EINVAL;
> -- 2.34.1
--
Ville Syrjälä
Intel
Re: [PATCH v2 00/21] drm/i915: Add Display Port tunnel BW allocation support
On Tue, Feb 20, 2024 at 11:18:20PM +0200, Imre Deak wrote: > This is v2 of [1], with the following changes: > > - Several functional/typo/formatting fixes, detailed in the patches. > - Move the BW allocation from encoder hooks to > intel_atomic_commit_tail() fixing the allocation for MST streams > enabled/disabled w/o a full modeset (i.e. w/o re-enabling the master > stream). > - Fix an MST mode restore issue during system resume, which also lead > to a tunnel BW allocation failure. (Patch 3) > - Ensure a DPCD DPRX cap read as required by the TBT CM any time a long > HPD pulse is detected. (Patch 20) > - Explicitly disable the BW allocation mode during system suspend. > > The patchset is also available at: > https://github.com/ideak/linux/commits/dp_tun_bw_alloc > > Cc: Mika Westerberg > Cc: Ville Syrjälä > Cc: Uma Shankar > Cc: Jouni Högander > Cc: Saranya Gopal > Cc: Rajaram Regupathy > Cc: Gil Fine > Cc: Naama Shachar > Cc: Pengfei Xu > > [1] https://lore.kernel.org/all/20240123102850.390126-1-imre.d...@intel.com > > Imre Deak (21): > drm/dp: Add drm_dp_max_dprx_data_rate() > drm/dp: Add support for DP tunneling > drm/i915: Fix display bpp limit computation during system resume > drm/i915/dp: Add support to notify MST connectors to retry modesets > drm/i915/dp: Use drm_dp_max_dprx_data_rate() > drm/i915/dp: Factor out intel_dp_config_required_rate() > drm/i915/dp: Export intel_dp_max_common_rate/lane_count() > drm/i915/dp: Factor out intel_dp_update_sink_caps() > drm/i915/dp: Factor out intel_dp_read_dprx_caps() > drm/i915/dp: Add intel_dp_max_link_data_rate() > drm/i915/dp: Add way to get active pipes with syncing commits > drm/i915/dp: Add support for DP tunnel BW allocation > drm/i915/dp: Add DP tunnel atomic state and check BW limit > drm/i915/dp: Account for tunnel BW limit in > intel_dp_max_link_data_rate() > drm/i915/dp: Compute DP tunnel BW during encoder state computation > drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable > hooks > drm/i915/dp: Handle DP tunnel IRQs > drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders > drm/i915/dp: Suspend/resume DP tunnels > drm/i915/dp: Read DPRX for all long HPD pulses > drm/i915/dp: Enable DP tunnel BW allocation mode I think I eyeballed this sufficiently now. Only a few minor issues which I pointed out already. Otherwise this is: Reviewed-by: Ville Syrjälä > > drivers/gpu/drm/display/Kconfig | 21 + > drivers/gpu/drm/display/Makefile |2 + > drivers/gpu/drm/display/drm_dp_helper.c | 30 + > drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 + > drivers/gpu/drm/i915/Kconfig | 14 + > drivers/gpu/drm/i915/Kconfig.debug|1 + > drivers/gpu/drm/i915/Makefile |3 + > drivers/gpu/drm/i915/display/intel_atomic.c | 10 + > drivers/gpu/drm/i915/display/intel_crtc.c | 52 + > drivers/gpu/drm/i915/display/intel_crtc.h |2 + > drivers/gpu/drm/i915/display/intel_ddi.c |3 +- > drivers/gpu/drm/i915/display/intel_display.c | 26 +- > .../gpu/drm/i915/display/intel_display_core.h |1 + > .../drm/i915/display/intel_display_driver.c | 20 +- > .../drm/i915/display/intel_display_types.h|9 + > drivers/gpu/drm/i915/display/intel_dp.c | 292 ++- > drivers/gpu/drm/i915/display/intel_dp.h | 13 +- > .../drm/i915/display/intel_dp_link_training.c | 33 +- > .../drm/i915/display/intel_dp_link_training.h |1 + > drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 +- > .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 +++ > .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 ++ > drivers/gpu/drm/i915/display/intel_link_bw.c | 27 +- > drivers/gpu/drm/i915/display/intel_link_bw.h |2 +- > drivers/gpu/drm/i915/display/intel_tc.c |7 + > include/drm/display/drm_dp.h | 61 + > include/drm/display/drm_dp_helper.h |2 + > include/drm/display/drm_dp_tunnel.h | 248 +++ > 28 files changed, 3650 insertions(+), 125 deletions(-) > create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h > create mode 100644 include/drm/display/drm_dp_tunnel.h > > -- > 2.39.2 -- Ville Syrjälä Intel
Re: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
On Sat, Feb 24, 2024 at 12:09:41AM +0200, Imre Deak wrote:
> On Fri, Feb 23, 2024 at 11:11:45PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 20, 2024 at 11:18:31PM +0200, Imre Deak wrote:
> > > Add a way to get the active pipes through a given DP port by syncing
> > > against a related pending non-blocking commit. Atm
> > > intel_dp_get_active_pipes() will only try to sync a given pipe and if
> > > that would block ignore the pipe. A follow-up change enabling the DP
> > > tunnel BW allocation mode will need to ensure that all active pipes are
> > > returned.
> > >
> > > This change will use intel_crtc_state::uapi.commit instead of the
> > > corresponding commit in the connector state. This shouldn't make a
> > > difference, since the two commit objects match for an active pipe.
> >
> > There is a slight difference here in that a non-modeset/fastset commit
> > will not have the connector inluded in the state and thus
> > connector->state.commit will be updated.
> >
> > I think the original idea of the code was to just skip anything that
> > looks like it's already undergoing a full modeset. With this we might
> > skip the retrain if there happens to be any kind of commit happening
> > on the crtc. Althoguh it seems that the original code is already
> > broken in the same way when there's a fastset happening in parallel.
>
> Ok, didn't think of it. Are you ok to sync instead of try-sync the pipes
> in case of link re-training?
Yeah, I guess that should be safer option, and we do recheck the
condition after the sync anyway so it shouldn't cause too much
extra stuff to happen. We can think about optimizing it correctly
later if necessary.
>
> > > A follow-up patchset will remove syncing during TC port reset, which
> > > should reset a port/pipe even if syncing against a commit would block.
> > > Syncing OTOH is not needed there, since the commit used for the reset
> > > implies a sync already. For now add a TODO comment for this.
> > >
> > > v2:
> > > - Add a separate function to try-sync the pipes. (Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> > > drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> > > drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> > > drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> > > 4 files changed, 37 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index 25593f6aae7de..17ed2e62cc66a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> > > *state,
> > > out:
> > > intel_psr_unlock(new_crtc_state);
> > > }
> > > +
> > > +/**
> > > + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of
> > > pipes
> > > + * @i915: i915 device object
> > > + * @pipe_mask: Mask of pipes to sync
> > > + *
> > > + * Try to sync a pending non-blocking commit for the provided pipes in
> > > + * @pipe_mask. The commit won't be synced if this would block.
> > > + *
> > > + * Return a mask of the pipes that got synced or didn't need syncing.
> > > + */
> > > +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> > > pipe_mask)
> > > +{
> > > + struct intel_crtc *crtc;
> > > + u32 synced = 0;
> > > +
> > > + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> > > + const struct intel_crtc_state *crtc_state =
> > > + to_intel_crtc_state(crtc->base.state);
> > > +
> > > + if (!crtc_state->uapi.commit ||
> > > + try_wait_for_completion(_state->uapi.commit->hw_done))
> > > + synced |= BIT(crtc->pipe);
> > > + }
> > > +
> > > + return synced;
> > > +}
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> > > b/drivers/gpu/drm/i915/display/intel_crtc.h
> > > index 22d7993d1f0ba..71a5b93166da7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> > > @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_
Re: [PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation
On Tue, Feb 20, 2024 at 11:18:32PM +0200, Imre Deak wrote:
> +static void queue_retry_work(struct intel_atomic_state *state,
> + struct drm_dp_tunnel *tunnel,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + struct intel_encoder *encoder;
> +
> + encoder = intel_get_crtc_new_encoder(state, crtc_state);
I was pondering what happens if we have no encoder here?
But I guess crtc_state->tunnel_ref.tunnel should be NULL in
that case and so we should not end up here.
> +
> + if (!intel_digital_port_connected(encoder))
> + return;
> +
> + drm_dbg_kms(>drm,
> + "[DPTUN %s][ENCODER:%d:%s] BW allocation failed on a
> connected sink\n",
> + drm_dp_tunnel_name(tunnel),
> + encoder->base.base.id,
> + encoder->base.name);
> +
> + intel_dp_queue_modeset_retry_for_link(state, encoder, crtc_state);
> +}
> +
--
Ville Syrjälä
Intel
Re: [PATCH v2 02/21] drm/dp: Add support for DP tunneling
On Tue, Feb 20, 2024 at 11:18:22PM +0200, Imre Deak wrote:
> +static inline void drm_dp_tunnel_ref_put(struct drm_dp_tunnel_ref
> *tunnel_ref)
> +{
> + drm_dp_tunnel_put(tunnel_ref->tunnel, _ref->tracker);
Should we set tunnel_ref->tunnel=NULL here?
--
Ville Syrjälä
Intel
Re: [PATCH v2 16/21] drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks
On Tue, Feb 20, 2024 at 11:18:36PM +0200, Imre Deak wrote: > Allocate and free the DP tunnel BW required by a stream while > enabling/disabling the stream during a modeset. > > v2: > - Move the allocation up from encoder hooks to > intel_atomic_commit_tail(). Subject should be adjusted to match. > > Signed-off-by: Imre Deak > Reviewed-by: Uma Shankar (v1) > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 1 + > drivers/gpu/drm/i915/display/intel_display.c | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index bea4415902044..ed7301808604d 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -54,6 +54,7 @@ > #include "intel_dp_aux.h" > #include "intel_dp_link_training.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_dpio_phy.h" > #include "intel_dsi.h" > #include "intel_fdi.h" > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 20647c97e86fa..445efe0087cde 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -7123,6 +7123,8 @@ static void intel_atomic_commit_tail(struct > intel_atomic_state *state) > > intel_commit_modeset_disables(state); > > + intel_dp_tunnel_atomic_alloc_bw(state); > + > /* FIXME: Eventually get rid of our crtc->config pointer */ > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > crtc->config = new_crtc_state; > -- > 2.39.2 -- Ville Syrjälä Intel
Re: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
On Tue, Feb 20, 2024 at 11:18:31PM +0200, Imre Deak wrote:
> Add a way to get the active pipes through a given DP port by syncing
> against a related pending non-blocking commit. Atm
> intel_dp_get_active_pipes() will only try to sync a given pipe and if
> that would block ignore the pipe. A follow-up change enabling the DP
> tunnel BW allocation mode will need to ensure that all active pipes are
> returned.
>
> This change will use intel_crtc_state::uapi.commit instead of the
> corresponding commit in the connector state. This shouldn't make a
> difference, since the two commit objects match for an active pipe.
There is a slight difference here in that a non-modeset/fastset commit
will not have the connector inluded in the state and thus
connector->state.commit will be updated.
I think the original idea of the code was to just skip anything that
looks like it's already undergoing a full modeset. With this we might
skip the retrain if there happens to be any kind of commit happening
on the crtc. Althoguh it seems that the original code is already
broken in the same way when there's a fastset happening in parallel.
>
> A follow-up patchset will remove syncing during TC port reset, which
> should reset a port/pipe even if syncing against a commit would block.
> Syncing OTOH is not needed there, since the commit used for the reset
> implies a sync already. For now add a TODO comment for this.
>
> v2:
> - Add a separate function to try-sync the pipes. (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> 4 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 25593f6aae7de..17ed2e62cc66a 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
> out:
> intel_psr_unlock(new_crtc_state);
> }
> +
> +/**
> + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of pipes
> + * @i915: i915 device object
> + * @pipe_mask: Mask of pipes to sync
> + *
> + * Try to sync a pending non-blocking commit for the provided pipes in
> + * @pipe_mask. The commit won't be synced if this would block.
> + *
> + * Return a mask of the pipes that got synced or didn't need syncing.
> + */
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask)
> +{
> + struct intel_crtc *crtc;
> + u32 synced = 0;
> +
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> + const struct intel_crtc_state *crtc_state =
> + to_intel_crtc_state(crtc->base.state);
> +
> + if (!crtc_state->uapi.commit ||
> + try_wait_for_completion(_state->uapi.commit->hw_done))
> + synced |= BIT(crtc->pipe);
> + }
> +
> + return synced;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> b/drivers/gpu/drm/i915/display/intel_crtc.h
> index 22d7993d1f0ba..71a5b93166da7 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
> drm_i915_private *i915,
> void intel_wait_for_vblank_if_active(struct drm_i915_private *i915,
>enum pipe pipe);
> void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d9e75922ff8f5..d0452d3e534a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp
> *intel_dp,
> if (!crtc_state->hw.active)
> continue;
>
> - if (conn_state->commit &&
> - !try_wait_for_completion(_state->commit->hw_done))
> - continue;
> -
> *pipe_mask |= BIT(crtc->pipe);
> }
> drm_connector_list_iter_end(_iter);
> @@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
> if (ret)
> return ret;
>
> + pipe_mask &= intel_crtc_try_sync_pipes(dev_p
Re: [PATCH] drm/i915: Add missing ; to __assign_str() macros in tracepoint code
On Thu, Feb 22, 2024 at 01:30:57PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> I'm working on improving the __assign_str() and __string() macros to be
> more efficient, and removed some unneeded semicolons. This triggered a bug
> in the build as some of the __assign_str() macros in intel_display_trace
> was missing a terminating semicolon.
>
> Fixes: 2ceea5d88048b ("drm/i915: Print plane name in fbc tracepoints")
> Signed-off-by: Steven Rostedt (Google)
Reviewed-by: Ville Syrjälä
Do you want me to apply this to drm-intel or do you want to take
it through some other tree? Either way seems fine for this stuff.
> ---
> drivers/gpu/drm/i915/display/intel_display_trace.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h
> b/drivers/gpu/drm/i915/display/intel_display_trace.h
> index 99bdb833591c..7862e7cefe02 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_trace.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
> @@ -411,7 +411,7 @@ TRACE_EVENT(intel_fbc_activate,
> struct intel_crtc *crtc =
> intel_crtc_for_pipe(to_i915(plane->base.dev),
>
> plane->pipe);
> __assign_str(dev, __dev_name_kms(plane));
> -__assign_str(name, plane->base.name)
> +__assign_str(name, plane->base.name);
> __entry->pipe = crtc->pipe;
> __entry->frame = intel_crtc_get_vblank_counter(crtc);
> __entry->scanline = intel_get_crtc_scanline(crtc);
> @@ -438,7 +438,7 @@ TRACE_EVENT(intel_fbc_deactivate,
> struct intel_crtc *crtc =
> intel_crtc_for_pipe(to_i915(plane->base.dev),
>
> plane->pipe);
> __assign_str(dev, __dev_name_kms(plane));
> -__assign_str(name, plane->base.name)
> +__assign_str(name, plane->base.name);
> __entry->pipe = crtc->pipe;
> __entry->frame = intel_crtc_get_vblank_counter(crtc);
> __entry->scanline = intel_get_crtc_scanline(crtc);
> @@ -465,7 +465,7 @@ TRACE_EVENT(intel_fbc_nuke,
> struct intel_crtc *crtc =
> intel_crtc_for_pipe(to_i915(plane->base.dev),
>
> plane->pipe);
> __assign_str(dev, __dev_name_kms(plane));
> -__assign_str(name, plane->base.name)
> +__assign_str(name, plane->base.name);
> __entry->pipe = crtc->pipe;
> __entry->frame = intel_crtc_get_vblank_counter(crtc);
> __entry->scanline = intel_get_crtc_scanline(crtc);
> --
> 2.43.0
--
Ville Syrjälä
Intel
Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Thu, Feb 22, 2024 at 11:54:04AM +0100, Maxime Ripard wrote: > On Mon, Feb 19, 2024 at 03:01:44PM +0100, Sebastian Wick wrote: > > On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote: > > > On Mon, Feb 12, 2024 at 06:06:18PM +0100, Sebastian Wick wrote: > > > > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > > > > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > > > > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard > > > > > > > > > > wrote: > > > > > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä > > > > > > > > > > > wrote: > > > > > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian > > > > > > > > > > > > > Wick wrote: > > > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > > > > > + * Indicates the RGB Quantization Range > > > > > > > > > > > > > > > > (Full vs Limited) used. > > > > > > > > > > > > > > > > + * Infoframes will be generated according > > > > > > > > > > > > > > > > to that value. > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > + * The value of this property can be one > > > > > > > > > > > > > > > > of the following: > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > > > > > + * RGB Range is selected > > > > > > > > > > > > > > > > automatically based on the mode > > > > > > > > > > > > > > > > + * according to the HDMI > > > > > > > > > > > > > > > > specifications. > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > + * Full: > > > > > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > > > > > + * Limited RGB Range is forced. > > > > > > > > > > > > > > > > Unlike the name suggests, > > > > > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > + * Drivers can set up this property by > > > > > > > > > > > > > > > > calling > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > drm_connector_attach_broadcast_rgb_property(). > > > > > > > &
Re: [PATCH v1] drivers/i915/intel_bios: Fix parsing backlight BDB data
On Tue, Feb 20, 2024 at 02:12:57PM -0700, Karthikeyan Ramasubramanian wrote:
> Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
> backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
> contents") updated the backlight BDB data accordingly. This broke the
> parsing of backlight BDB data in VBT for versions 236 - 238 (both
> inclusive) and hence the backlight controls are not responding on units
> with the concerned BDB version.
>
> backlight_control information has been present in backlight BDB data
> from at least BDB version 191 onwards, if not before. Hence this patch
> extracts the backlight_control information if the block size of
> backlight BDB is >= version 191 backlight BDB block size.
> Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236).
> Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251).
>
> Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents")
> Cc: sta...@vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Karthikeyan Ramasubramanian
> ---
>
> drivers/gpu/drm/i915/display/intel_bios.c | 22 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 --
> 2 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index aa169b0055e97..4ec50903b9e64 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1041,23 +1041,13 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>
> panel->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> panel->vbt.backlight.controller = 0;
> - if (i915->display.vbt.version >= 191) {
> - size_t exp_size;
> + if (i915->display.vbt.version >= 191 &&
> + get_blocksize(backlight_data) >= EXP_BDB_LFP_BL_DATA_SIZE_REV_191) {
The size checks looks like nonsense to me. I guess maybe
we needed it before we were guaranteed to have the full
struct's worth of memory. But there should be no need for
this anymore.
> + const struct lfp_backlight_control_method *method;
>
> - if (i915->display.vbt.version >= 236)
> - exp_size = sizeof(struct bdb_lfp_backlight_data);
> - else if (i915->display.vbt.version >= 234)
> - exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> - else
> - exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_191;
> -
> - if (get_blocksize(backlight_data) >= exp_size) {
> - const struct lfp_backlight_control_method *method;
> -
> - method = _data->backlight_control[panel_type];
> - panel->vbt.backlight.type = method->type;
> - panel->vbt.backlight.controller = method->controller;
> - }
> + method = _data->backlight_control[panel_type];
> + panel->vbt.backlight.type = method->type;
> + panel->vbt.backlight.controller = method->controller;
> }
>
> panel->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index a9f44abfc9fc2..aeea5635a37ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -899,8 +899,6 @@ struct lfp_brightness_level {
>
> #define EXP_BDB_LFP_BL_DATA_SIZE_REV_191 \
> offsetof(struct bdb_lfp_backlight_data, brightness_level)
> -#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> - offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
>
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> --
> 2.44.0.rc0.258.g7320e95886-goog
--
Ville Syrjälä
Intel
Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
On Tue, Feb 20, 2024 at 11:27:18AM -0800, Abhinav Kumar wrote: > > > On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote: > > On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov > > wrote: > >> > >> On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar > >> wrote: > >>> > >>> > >>> > >>> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote: > >>>> On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar > >>>> wrote: > >>>>> > >>>>> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well. > >>>>> Lets move this to drm_dp_helper to achieve this. > >>>>> > >>>>> changes in v2: > >>>>> - rebased on top of drm-tip > >>>>> > >>>>> Acked-by: Dmitry Baryshkov > >>>> > >>>> v1 had an explicit comment before the ack: > >>>> > >>> > >>> Yes, I remember the comment. I did not make any changes to v2 other than > >>> just rebasing it on drm-tip to get the ack from i915 folks. > >>> > >>>>> From my side, with the promise of the size fixup. > >>>> > >>>> However I observe neither a second patch removing the size argument > >>>> nor it being dropped as a part of this patch. > >>>> > >>> > >>> Yes, now that in v2 we got the ack for this patch, I can spin a v3 with > >>> the addition of the next patch to remove the size OR as another series > >>> so as to not block the main series which needs this patch. > >>> > >>> I would prefer the latter. > >> > >> It doesn't work this way. The comment should have been fixed for v2. > > > > This probably deserves some explanation. Currently there is only one > > user of this function. So it is easy to fix it. Once there are several > > users, you have to fix all of them at the same time, patching > > different drm subtrees. That complicates the life of maintainers. > > > > Yes, understood. Its easier to fix it now if its really needed. > > Actually, I think the reason the size was passed was to make sure > a valid struct dp_sdp *sdp was being passed. The size is supposed to be the size of *hardware* buffer where this gets written into. But looks like this wasn't done correctly when the code was copy-pasted from the HDMI inforframe code. -- Ville Syrjälä Intel
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > to update all the users of the struct drm_tv_connector_state mode field,
> > > which resulted in a build failure in i915.
> > >
> > > However, a subsequent commit in the same series reintroduced a mode
> > > field in that structure, with a different semantic but the same type,
> > > with the assumption that all previous users were updated.
> > >
> > > Since that didn't happen, the i915 driver now compiles, but mixes
> > > accesses to the legacy_mode field and the newer mode field, but with the
> > > previous semantics.
> > >
> > > This obviously doesn't work very well, so we need to update the accesses
> > > that weren't in the legacy renaming commit.
> > >
> > > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > > Reported-by: Ville Syrjälä
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > > 2 files changed, 10 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > index 825638702ac1..5f9e748adc89 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > > intel_sdvo *intel_sdvo,
> > > struct intel_sdvo_tv_format format;
> > > u32 format_map;
> > >
> > > - format_map = 1 << conn_state->tv.mode;
> > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > memset(, 0, sizeof(format));
> > > memcpy(, _map, min(sizeof(format), sizeof(format_map)));
> > >
> > > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > > drm_connector *connector)
> > >* Read the list of supported input resolutions for the selected TV
> > >* format.
> > >*/
> > > - format_map = 1 << conn_state->tv.mode;
> > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > memcpy(_res, _map,
> > > min(sizeof(format_map), sizeof(struct
> > > intel_sdvo_sdtv_resolution_request)));
> > >
> > > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > > drm_connector *connector,
> > > int i;
> > >
> > > for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> > > - if (state->tv.mode ==
> > > intel_sdvo_connector->tv_format_supported[i]) {
> > > + if (state->tv.legacy_mode ==
> > > intel_sdvo_connector->tv_format_supported[i]) {
> > > *val = i;
> > >
> > > return 0;
> > > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > > drm_connector *connector,
> > > struct intel_sdvo_connector_state *sdvo_state =
> > > to_intel_sdvo_connector_state(state);
> > >
> > > if (property == intel_sdvo_connector->tv_format) {
> > > - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> > > + state->tv.legacy_mode =
> > > intel_sdvo_connector->tv_format_supported[val];
> > >
> > > if (state->crtc) {
> > > struct drm_crtc_state *crtc_state =
> > > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> > > intel_sdvo *intel_sdvo,
> > > drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> > >
> > > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> > >
> > > - intel_sdvo_connector->base.base.state->tv.mode =
> > > intel_sdvo_connector->tv_format_supported[0];
> > > + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> > > intel_sdvo_connector->tv_format_supported[0];
> > > drm_object_attach_property(_sdvo_connector->base.base.base,
> > >
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
>
> However, a subsequent commit in the same series reintroduced a mode
> field in that structure, with a different semantic but the same type,
> with the assumption that all previous users were updated.
>
> Since that didn't happen, the i915 driver now compiles, but mixes
> accesses to the legacy_mode field and the newer mode field, but with the
> previous semantics.
>
> This obviously doesn't work very well, so we need to update the accesses
> that weren't in the legacy renaming commit.
>
> Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> Reported-by: Ville Syrjälä
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 825638702ac1..5f9e748adc89 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct intel_sdvo
> *intel_sdvo,
> struct intel_sdvo_tv_format format;
> u32 format_map;
>
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memset(, 0, sizeof(format));
> memcpy(, _map, min(sizeof(format), sizeof(format_map)));
>
> @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct drm_connector
> *connector)
>* Read the list of supported input resolutions for the selected TV
>* format.
>*/
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memcpy(_res, _map,
> min(sizeof(format_map), sizeof(struct
> intel_sdvo_sdtv_resolution_request)));
>
> @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> drm_connector *connector,
> int i;
>
> for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> - if (state->tv.mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> + if (state->tv.legacy_mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> *val = i;
>
> return 0;
> @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> drm_connector *connector,
> struct intel_sdvo_connector_state *sdvo_state =
> to_intel_sdvo_connector_state(state);
>
> if (property == intel_sdvo_connector->tv_format) {
> - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> + state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[val];
>
> if (state->crtc) {
> struct drm_crtc_state *crtc_state =
> @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> intel_sdvo *intel_sdvo,
> drm_property_add_enum(intel_sdvo_connector->tv_format, i,
>
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>
> - intel_sdvo_connector->base.base.state->tv.mode =
> intel_sdvo_connector->tv_format_supported[0];
> + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[0];
> drm_object_attach_property(_sdvo_connector->base.base.base,
> intel_sdvo_connector->tv_format, 0);
> return true;
Hmm. I didn't realize we are using this in the SDVO code as well.
I don't *think* that one is actually broken since it has its own
.{set,get}_property() hooks. But I suppose doing the rename
there as well is a good idea anyway.
Can you split the SDVO vs. TV into separate patches? We need to
backport at least the TV part, and a smaller patch means less
chance of conflicts. Or if you prefer I can chunk it up while
pushing.
Both parts are
Reviewed-by: Ville Syrjälä
Thanks.
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index a96bcfcf90a3..2b77d399f1a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -950,7 +950,7 @@ intel_disable_tv(struc
Re: [PATCH v3 6/8] drm: add drm_mode_atomic_commit event
lags;
> + ),
> + TP_printk("file=%p, pid=%8d, flags=%08x, crtcs=%s", __entry->file,
> + pid_nr(__entry->file->pid), __entry->flags,
> + __print_array(__get_dynamic_array(crtcs),
> __entry->ncrtcs, 4))
> +);
> +
> #endif /* _DRM_TRACE_H_ */
>
> /* This part must be outside protection */
> --
> 2.40.1
--
Ville Syrjälä
Intel
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> On 2/14/2024 17:13, Ville Syrjälä wrote:
> > On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >> Some manufacturers have intentionally put an EDID that differs from
> >> the EDID on the internal panel on laptops. Drivers that prefer to
> >> fetch this EDID can set a bit on the drm_connector to indicate that
> >> the DRM EDID helpers should try to fetch it and it is preferred if
> >> it's present.
> >>
> >> Signed-off-by: Mario Limonciello
> >> ---
> >> drivers/gpu/drm/Kconfig | 1 +
> >> drivers/gpu/drm/drm_edid.c | 109 +---
> >> include/drm/drm_connector.h | 6 ++
> >> include/drm/drm_edid.h | 1 +
> >> 4 files changed, 109 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index 872edb47bb53..3db89e6af01d 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -8,6 +8,7 @@
> >> menuconfig DRM
> >>tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
> >> support)"
> >>depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> >> + depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> >>select DRM_PANEL_ORIENTATION_QUIRKS
> >>select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
> >>select FB_CORE if DRM_FBDEV_EMULATION
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 923c4423151c..cdc30c6d05d5 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -28,6 +28,7 @@
> >>* DEALINGS IN THE SOFTWARE.
> >>*/
> >>
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned
> >> int block, size_t len)
> >>return ret == xfers ? 0 : -1;
> >> }
> >>
> >> +/**
> >> + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
> >> + * @data: struct drm_connector
> >> + * @buf: EDID data buffer to be filled
> >> + * @block: 128 byte EDID block to start fetching from
> >> + * @len: EDID data buffer length to fetch
> >> + *
> >> + * Try to fetch EDID information by calling acpi_video_get_edid()
> >> function.
> >> + *
> >> + * Return: 0 on success or error code on failure.
> >> + */
> >> +static int
> >> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t
> >> len)
> >> +{
> >> + struct drm_connector *connector = data;
> >> + struct drm_device *ddev = connector->dev;
> >> + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
> >> + unsigned char start = block * EDID_LENGTH;
> >> + void *edid;
> >> + int r;
> >> +
> >> + if (!acpidev)
> >> + return -ENODEV;
> >> +
> >> + switch (connector->connector_type) {
> >> + case DRM_MODE_CONNECTOR_LVDS:
> >> + case DRM_MODE_CONNECTOR_eDP:
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >
> > We could have other types of connectors that want this too.
> > I don't see any real benefit in having this check tbh. Drivers
> > should simply notset the flag on connectors where it won't work,
> > and only the driver can really know that.
>
> Ack.
>
> >
> >> + /* fetch the entire edid from BIOS */
> >> + r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
> >> + if (r < 0) {
> >> + DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
> >> + return r;
> >> + }
> >> + if (len > r || start > r || start + len > r) {
> >> + r = -EINVAL;
> >> + goto cleanup;
> >> + }
> >> +
> >> + memcpy(buf, edid + start, len);
> >> + r = 0;
> >> +
> >> +cleanup:
> >> + kfree(edid);
> >> +
> >> + return r;
> >> +}
> >> +
> >> static void connector_bad_edid(struct drm_connector *connector,
> >> const struct edid *edid, int num_blocks)
> >> {
> >> @@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
&
Re: [RFC 0/5] Introduce drm sharpening property
On Thu, Feb 15, 2024 at 11:37:54AM -0500, Harry Wentland wrote: > Adding a couple of compositor devs as they might be interested in this. > > On 2024-02-14 06:24, Nemesa Garg wrote: > > Many a times images are blurred or upscaled content is also not as > > crisp as original rendered image. Traditional sharpening techniques often > > apply a uniform level of enhancement across entire image, which sometimes > > result in over-sharpening of some areas and potential loss of natural > > details. > > > > Intel has come up with Display Engine based adaptive sharpening filter > > with minimal power and performance impact. From LNL onwards, the Display > > hardware can use one of the pipe scaler for adaptive sharpness filter. > > This can be used for both gaming and non-gaming use cases like photos, > > image viewing. It works on a region of pixels depending on the tap size. > > > > This RFC is an attempt to introduce an adaptive sharpness solution which > > helps in improving the image quality. For this new CRTC property is added. > > I don't think CRTC is the right place for this. Scaling tends to be more > of a plane thing. Planes can be scaled independently, or is that not the > case for Intel? Or does Intel HW do this sharpening operation independent > of any scaling, on the entire output? We can scale either individual planes, or the entire crtc. > > > The user can set this property with desired sharpness strength value with > > 0-255. A value of 1 representing minimum sharpening strength and 255 > > representing maximum sharpness strength. A strength value of 0 means no > > sharpening or sharpening feature disabled. > > It works on a region of pixels depending on the tap size. The coefficients > > are used to generate an alpha value which is used to blend the sharpened > > image to original image. > > > > Userspace implementation for sharpening feature and IGT implementation > > is in progress. > > It would be very helpful to have an idea how this looks in userspace, and > which compositors will implement this. Someone will probably need to spend some real time thinking how this interacts with the scaling filter propery (eg. if we want to extend that property with new values) and the laptop panel scaling mode property. We also want to implement the margin properties for external displays which also involves scaling. Ie. we need some kind of consistent story how all those things will work together. > > Harry > > > > > Nemesa Garg (5): > > drm: Introduce sharpeness mode property > > drm/i915/display/: Compute the scaler filter coefficients > > drm/i915/dispaly/: Enable the second scaler > > drm/i915/display/: Add registers and compute the strength > > drm/i915/display: Load the lut values and enable sharpness > > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 + > > drivers/gpu/drm/drm_crtc.c| 17 ++ > > drivers/gpu/drm/i915/Makefile | 1 + > > drivers/gpu/drm/i915/display/intel_crtc.c | 3 + > > drivers/gpu/drm/i915/display/intel_display.c | 20 +- > > .../drm/i915/display/intel_display_types.h| 11 + > > .../drm/i915/display/intel_modeset_verify.c | 1 + > > .../drm/i915/display/intel_sharpen_filter.c | 214 ++ > > .../drm/i915/display/intel_sharpen_filter.h | 31 +++ > > drivers/gpu/drm/i915/display/skl_scaler.c | 86 ++- > > drivers/gpu/drm/i915/display/skl_scaler.h | 1 + > > drivers/gpu/drm/i915/i915_reg.h | 19 ++ > > drivers/gpu/drm/xe/Makefile | 1 + > > include/drm/drm_crtc.h| 17 ++ > > 14 files changed, 416 insertions(+), 10 deletions(-) > > create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.c > > create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.h > > -- Ville Syrjälä Intel
Re: [PATCH v2 2/6] drm/i915/mst: improve debug logging of DP MST mode detect
On Thu, Feb 15, 2024 at 01:46:48PM +0200, Jani Nikula wrote:
> On Wed, 14 Feb 2024, Ville Syrjälä wrote:
> > On Tue, Feb 13, 2024 at 01:30:57PM +0200, Jani Nikula wrote:
> >> Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
> >> detect debug logging there. Debug log the sink's MST capability,
> >> including single-stream sideband messaging support, and the decision
> >> whether to enable MST mode or not. Do this regardless of whether we're
> >> actually enabling MST or not.
> >>
> >> Cc: Arun R Murthy
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dp.c | 45 +
> >> 1 file changed, 31 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index a1c304f451bd..944f566525dd 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -4007,31 +4007,48 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >> intel_dp->downstream_ports) == 0;
> >> }
> >>
> >> +static const char *intel_dp_mst_mode_str(enum drm_dp_mst_mode mst_mode)
> >> +{
> >> + if (mst_mode == DRM_DP_SST_SIDEBAND_MSG)
> >> + return "single-stream sideband messaging";
> >> + else
> >> + return str_yes_no(mst_mode == DRM_DP_MST);
> >
> > I wonder if this should also just say "sst"/"mst"/"sst sideband" etc.
> > Shrug.
> >
> > Reviewed-by: Ville Syrjälä
>
> I realize there's an issue here.
>
> intel_dp_detect_dpcd() bails out early for !drm_dp_is_branch(), before
> the intel_dp_can_mst() call. (Renamed intel_dp_mst_detect() here.)
>
> We'll still happily call intel_dp_configure_mst() later also for
> !branch.
>
> We'll need to call intel_dp_mst_detect() earlier and/or somehow combine
> these together. I don't think branch devices need to support MST, but I
> think MST devices need to support branching. And single-stream sideband
> support does not mean branching.
>
> The intention of this patch was to improve MST debug logging, but the
> end result is that it reduces it! Auch.
>
> I wonder if we should branch (eh) the detect earlier for eDP, SST and
> MST/branch paths. Just to make it easier for our poor brains to follow.
Hmm. The sink count check is another case as well. If the device
has a local sink, or somehting connected to its DFP(s) it should
declare sink count >= 1.
--
Ville Syrjälä
Intel
Re: Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Thu, Feb 15, 2024 at 11:53:17AM +0100, Maxime Ripard wrote: > On Tue, Feb 13, 2024 at 10:38:56AM +0200, Ville Syrjälä wrote: > > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard > > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick > > > > > > > > > > > wrote: > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > > > * > > > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full > > > > > > > > > > > > > > vs Limited) used. > > > > > > > > > > > > > > + * Infoframes will be generated according to > > > > > > > > > > > > > > that value. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * The value of this property can be one of > > > > > > > > > > > > > > the following: > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > > > + * RGB Range is selected > > > > > > > > > > > > > > automatically based on the mode > > > > > > > > > > > > > > + * according to the HDMI > > > > > > > > > > > > > > specifications. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Full: > > > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > > > + * Limited RGB Range is forced. > > > > > > > > > > > > > > Unlike the name suggests, > > > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. > > > > > > > > > > > > > There might be two > > > > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > &g
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
(connector, drm_do_probe_acpi_edid,
> connector, NULL);
> +
> + if (!edid) {
> + if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> + return NULL;
> + edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
> adapter, NULL);
> + }
>
> - edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter,
> NULL);
> drm_connector_update_edid_property(connector, edid);
> return edid;
> }
> EXPORT_SYMBOL(drm_get_edid);
>
> +/**
> + * drm_edid_read_acpi - get EDID data, if available
> + * @connector: connector we're probing
> + *
> + * Use the BIOS to attempt to grab EDID data if possible.
> + *
> + * The returned pointer must be freed using drm_edid_free().
> + *
> + * Return: Pointer to valid EDID or NULL if we couldn't find any.
> + */
> +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector)
> +{
> + const struct drm_edid *drm_edid;
> +
> + if (connector->force == DRM_FORCE_OFF)
> + return NULL;
> +
> + drm_edid = drm_edid_read_custom(connector, drm_do_probe_acpi_edid,
> connector);
> +
> + /* Note: Do *not* call connector updates here. */
> +
> + return drm_edid;
> +}
> +EXPORT_SYMBOL(drm_edid_read_acpi);
> +
> /**
> * drm_edid_read_custom - Read EDID data using given EDID block read function
> * @connector: Connector to use
> @@ -2727,10 +2811,11 @@ const struct drm_edid *drm_edid_read_ddc(struct
> drm_connector *connector,
> EXPORT_SYMBOL(drm_edid_read_ddc);
>
> /**
> - * drm_edid_read - Read EDID data using connector's I2C adapter
> + * drm_edid_read - Read EDID data using BIOS or connector's I2C adapter
> * @connector: Connector to use
> *
> - * Read EDID using the connector's I2C adapter.
> + * Read EDID from BIOS if allowed by connector or by using the connector's
> + * I2C adapter.
> *
> * The EDID may be overridden using debugfs override_edid or firmware EDID
> * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this
> priority
> @@ -2742,10 +2827,18 @@ EXPORT_SYMBOL(drm_edid_read_ddc);
> */
> const struct drm_edid *drm_edid_read(struct drm_connector *connector)
> {
> + const struct drm_edid *drm_edid = NULL;
> +
> if (drm_WARN_ON(connector->dev, !connector->ddc))
> return NULL;
>
> - return drm_edid_read_ddc(connector, connector->ddc);
> + if (connector->acpi_edid_allowed)
That should probably be called 'prefer_acpi_edid' or something
since it's the first choice when the flag is set.
But I'm not so sure there's any real benefit in having this
flag at all. You anyway have to modify the driver to use this,
so why not just have the driver do the call directly instead of
adding this extra detour via the flag?
> + drm_edid = drm_edid_read_acpi(connector);
> +
> + if (!drm_edid)
> + drm_edid = drm_edid_read_ddc(connector, connector->ddc);
> +
> + return drm_edid;
> }
> EXPORT_SYMBOL(drm_edid_read);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fe88d7fc6b8f..74ed47f37a69 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1886,6 +1886,12 @@ struct drm_connector {
>
> /** @hdr_sink_metadata: HDR Metadata Information read from sink */
> struct hdr_sink_metadata hdr_sink_metadata;
> +
> + /**
> + * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> + * This is only applicable to eDP and LVDS displays.
> + */
> + bool acpi_edid_allowed;
Aren't there other bools/small stuff in there for tighter packing?
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7923bc00dc7a..1c1ee927de9c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -459,5 +459,6 @@ bool drm_edid_is_digital(const struct drm_edid *drm_edid);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector);
>
> #endif /* __DRM_EDID_H__ */
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On Wed, Feb 14, 2024 at 09:17:06PM +0200, Dmitry Baryshkov wrote: > On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä > wrote: > > > > On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote: > > > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote: > > > > The helper drm_atomic_helper_check_plane_state() runs several checks on > > > > plane src and dst rectangles, including the check whether required > > > > scaling fits into the required margins. The msm driver would benefit > > > > from having a function that does all these checks except the scaling > > > > one. Split them into a new helper called > > > > drm_atomic_helper_check_plane_noscale(). > > > > > > What's the point in eliminating a nop scaling check? > > > > Actually, what are you even doing in there? Are you saying that > > the hardware has absolutely no limits on how much it can scale > > in either direction? > > No, I'm just saying that the scaling ability depends on the rotation > and other plane properties. So I had to separate the basic plane > checks and the scaling check. > Basic (noscale) plane check source and destination rectangles, etc. > After that the driver identifies possible hardware pipe usage and > after that it can perform a scaling check. Hmm. We have sport of similar situation in i915 where we pick a scaler much later and so don't know the exact scaling limits at the time when we do this check. But we opted to pass the lower/upper bounds of the scaling limits instead. That will guarantee that at least completely illegal values are rejected as early as possible, and so we don't have to worry about running into them later on. -- Ville Syrjälä Intel
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> > The helper drm_atomic_helper_check_plane_state() runs several checks on
> > plane src and dst rectangles, including the check whether required
> > scaling fits into the required margins. The msm driver would benefit
> > from having a function that does all these checks except the scaling
> > one. Split them into a new helper called
> > drm_atomic_helper_check_plane_noscale().
>
> What's the point in eliminating a nop scaling check?
Actually, what are you even doing in there? Are you saying that
the hardware has absolutely no limits on how much it can scale
in either direction?
>
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 110 ++--
> > include/drm/drm_atomic_helper.h | 7 ++
> > 2 files changed, 96 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 292e38eb6218..2d7dd66181c9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -825,11 +825,9 @@ drm_atomic_helper_check_wb_encoder_state(struct
> > drm_encoder *encoder,
> > EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
> >
> > /**
> > - * drm_atomic_helper_check_plane_state() - Check plane state for validity
> > + * drm_atomic_helper_check_plane_noscale() - Check plane state for validity
> > * @plane_state: plane state to check
> > * @crtc_state: CRTC state to check
> > - * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> > - * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> > * @can_position: is it legal to position the plane such that it
> > *doesn't cover the entire CRTC? This will generally
> > *only be false for primary planes.
> > @@ -845,19 +843,16 @@
> > EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
> > * RETURNS:
> > * Zero if update appears valid, error code on failure
> > */
> > -int drm_atomic_helper_check_plane_state(struct drm_plane_state
> > *plane_state,
> > - const struct drm_crtc_state *crtc_state,
> > - int min_scale,
> > - int max_scale,
> > - bool can_position,
> > - bool can_update_disabled)
> > +int drm_atomic_helper_check_plane_noscale(struct drm_plane_state
> > *plane_state,
> > + const struct drm_crtc_state
> > *crtc_state,
> > + bool can_position,
> > + bool can_update_disabled)
> > {
> > struct drm_framebuffer *fb = plane_state->fb;
> > struct drm_rect *src = _state->src;
> > struct drm_rect *dst = _state->dst;
> > unsigned int rotation = plane_state->rotation;
> > struct drm_rect clip = {};
> > - int hscale, vscale;
> >
> > WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
> >
> > @@ -883,17 +878,6 @@ int drm_atomic_helper_check_plane_state(struct
> > drm_plane_state *plane_state,
> >
> > drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
> >
> > - /* Check scaling */
> > - hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> > - vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> > - if (hscale < 0 || vscale < 0) {
> > - drm_dbg_kms(plane_state->plane->dev,
> > - "Invalid scaling of plane\n");
> > - drm_rect_debug_print("src: ", _state->src, true);
> > - drm_rect_debug_print("dst: ", _state->dst, false);
> > - return -ERANGE;
> > - }
> > -
> > if (crtc_state->enable)
> > drm_mode_get_hv_timing(_state->mode, , );
> >
> > @@ -921,6 +905,90 @@ int drm_atomic_helper_check_plane_state(struct
> > drm_plane_state *plane_state,
> >
> > return 0;
> > }
> > +EXPORT_SYMBOL(drm_atomic_helper_check_plane_noscale);
> > +
> > +/**
> > + * drm_atomic_helper_check_plane_scale() - Check whether plane can be
> > scaled
> > + * @plane_state: plane st
Re: [PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
_state *plane_state,
> + int min_scale,
> + int max_scale)
> +{
> + struct drm_framebuffer *fb = plane_state->fb;
> + struct drm_rect src;
> + struct drm_rect dst;
> + int hscale, vscale;
> +
> + if (!plane_state->visible)
> + return 0;
> +
> + src = drm_plane_state_src(plane_state);
> + dst = drm_plane_state_dest(plane_state);
> +
> + drm_rect_rotate(, fb->width << 16, fb->height << 16,
> plane_state->rotation);
> +
> + hscale = drm_rect_calc_hscale(, , min_scale, max_scale);
> + vscale = drm_rect_calc_vscale(, , min_scale, max_scale);
> + if (hscale < 0 || vscale < 0) {
> + drm_dbg_kms(plane_state->plane->dev,
> + "Invalid scaling of plane\n");
> + drm_rect_debug_print("src: ", _state->src, true);
> + drm_rect_debug_print("dst: ", _state->dst, false);
> + return -ERANGE;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_check_plane_scale);
> +
> +/**
> + * drm_atomic_helper_check_plane_state() - Check plane state for validity
> + * @plane_state: plane state to check
> + * @crtc_state: CRTC state to check
> + * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> + * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> + * @can_position: is it legal to position the plane such that it
> + *doesn't cover the entire CRTC? This will generally
> + *only be false for primary planes.
> + * @can_update_disabled: can the plane be updated while the CRTC
> + * is disabled?
> + *
> + * Checks that a desired plane update is valid, and updates various
> + * bits of derived state (clipped coordinates etc.). Drivers that provide
> + * their own plane handling rather than helper-provided implementations may
> + * still wish to call this function to avoid duplication of error checking
> + * code.
> + *
> + * RETURNS:
> + * Zero if update appears valid, error code on failure
> + */
> +int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
> + const struct drm_crtc_state *crtc_state,
> + int min_scale,
> + int max_scale,
> + bool can_position,
> + bool can_update_disabled)
> +{
> + int ret;
> +
> + ret = drm_atomic_helper_check_plane_noscale(plane_state, crtc_state,
> can_position, can_update_disabled);
> + if (ret < 0)
> + return ret;
> +
> + return drm_atomic_helper_check_plane_scale(plane_state, min_scale,
> max_scale);
> +}
> EXPORT_SYMBOL(drm_atomic_helper_check_plane_state);
>
> /**
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 536a0b0091c3..32ac55aea94e 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -52,6 +52,13 @@ int drm_atomic_helper_check_modeset(struct drm_device *dev,
> int
> drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
>struct drm_connector_state
> *conn_state);
> +int drm_atomic_helper_check_plane_noscale(struct drm_plane_state
> *plane_state,
> + const struct drm_crtc_state
> *crtc_state,
> + bool can_position,
> + bool can_update_disabled);
> +int drm_atomic_helper_check_plane_scale(struct drm_plane_state *plane_state,
> + int min_scale,
> + int max_scale);
> int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
> const struct drm_crtc_state *crtc_state,
> int min_scale,
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 5/6] drm/i915/mst: add intel_dp_mst_disconnect()
On Tue, Feb 13, 2024 at 01:31:00PM +0200, Jani Nikula wrote:
> Abstract the MST mode disconnect to a separate function.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 72e91322e310..7f97d5512a3e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4069,6 +4069,20 @@ intel_dp_mst_configure(struct intel_dp *intel_dp)
> intel_dp->mst_detect = DRM_DP_SST;
> }
>
> +static void
> +intel_dp_mst_disconnect(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (!intel_dp->is_mst)
> + return;
> +
> + drm_dbg_kms(>drm, "MST device may have disappeared %d vs %d\n",
> + intel_dp->is_mst, intel_dp->mst_mgr.mst_state);
> + intel_dp->is_mst = false;
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst);
> +}
> +
> static bool
> intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *esi)
> {
> @@ -5721,15 +5735,7 @@ intel_dp_detect(struct drm_connector *connector,
> memset(intel_connector->dp.dsc_dpcd, 0,
> sizeof(intel_connector->dp.dsc_dpcd));
> intel_dp->psr.sink_panel_replay_support = false;
>
> - if (intel_dp->is_mst) {
> - drm_dbg_kms(_priv->drm,
> - "MST device may have disappeared %d vs
> %d\n",
> - intel_dp->is_mst,
> - intel_dp->mst_mgr.mst_state);
> - intel_dp->is_mst = false;
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> - intel_dp->is_mst);
> - }
> + intel_dp_mst_disconnect(intel_dp);
>
> goto out;
> }
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 4/6] drm/i915/mst: use the MST mode detected previously
On Tue, Feb 13, 2024 at 01:30:59PM +0200, Jani Nikula wrote:
> Drop the duplicate read of DP_MSTM_CAP DPCD register, and the duplicate
> logic for choosing MST mode, and store the chosen mode in struct
> intel_dp. Rename intel_dp_configure_mst() to intel_dp_mst_configure()
> while at it.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 23 ---
> 2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 01eb6e4e6049..4a8440a3a812 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1780,6 +1780,7 @@ struct intel_dp {
>
> bool is_mst;
> int active_mst_links;
> + enum drm_dp_mst_mode mst_detect;
>
> /* connector directly attached - won't be use for modeset in mst world
> */
> struct intel_connector *attached_connector;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 007cb2a04e38..72e91322e310 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4039,11 +4039,10 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> enum drm_dp_mst_mode sink_mst_mode;
> - enum drm_dp_mst_mode mst_detect;
>
> sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
>
> - mst_detect = intel_dp_mst_mode_choose(intel_dp, sink_mst_mode);
> + intel_dp->mst_detect = intel_dp_mst_mode_choose(intel_dp,
> sink_mst_mode);
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s -> enable: %s\n",
> @@ -4051,25 +4050,23 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
> str_yes_no(intel_dp_mst_source_support(intel_dp)),
> intel_dp_mst_mode_str(sink_mst_mode),
> str_yes_no(i915->display.params.enable_dp_mst),
> - intel_dp_mst_mode_str(mst_detect));
> + intel_dp_mst_mode_str(intel_dp->mst_detect));
>
> - return mst_detect != DRM_DP_SST;
> + return intel_dp->mst_detect != DRM_DP_SST;
> }
>
> static void
> -intel_dp_configure_mst(struct intel_dp *intel_dp)
> +intel_dp_mst_configure(struct intel_dp *intel_dp)
> {
> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DRM_DP_MST;
> -
> if (!intel_dp_mst_source_support(intel_dp))
> return;
I was wondering if we even need that, but it looks to be just a
check to see if we actually initialized the mst_mgt or not.
We should probably rename it or something... Or perhaps we could
tweak the topology manager a bit so we wouldn't need to check...
>
> - intel_dp->is_mst = sink_can_mst &&
> - i915->display.params.enable_dp_mst;
> + intel_dp->is_mst = intel_dp->mst_detect != DRM_DP_SST;
> +
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst);
>
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> - intel_dp->is_mst);
> + /* Avoid stale info on the next detect cycle. */
> + intel_dp->mst_detect = DRM_DP_SST;
Hmm. Not sure I like having ephemeral stuff like this in intel_dp,
but I guess the alternative would be plumb it up from detect_dpcd()
by hand, which might not be super pretty either. Oh well.
Reviewed-by: Ville Syrjälä
> }
>
> static bool
> @@ -5739,7 +5736,7 @@ intel_dp_detect(struct drm_connector *connector,
>
> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>
> - intel_dp_configure_mst(intel_dp);
> + intel_dp_mst_configure(intel_dp);
>
> /*
>* TODO: Reset link params when switching to MST mode, until MST
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 3/6] drm/i915/mst: abstract choosing the MST mode to use
On Tue, Feb 13, 2024 at 01:30:58PM +0200, Jani Nikula wrote:
> Clarify the conditions for choosing the MST mode to use by adding a new
> function intel_dp_mst_mode_choose(). This also prepares for being able
> to extend the MST modes to single-stream sideband messaging.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 944f566525dd..007cb2a04e38 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4015,6 +4015,24 @@ static const char *intel_dp_mst_mode_str(enum
> drm_dp_mst_mode mst_mode)
> return str_yes_no(mst_mode == DRM_DP_MST);
> }
>
> +static enum drm_dp_mst_mode
> +intel_dp_mst_mode_choose(struct intel_dp *intel_dp,
> + enum drm_dp_mst_mode sink_mst_mode)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (!i915->display.params.enable_dp_mst)
> + return DRM_DP_SST;
> +
> + if (!intel_dp_mst_source_support(intel_dp))
> + return DRM_DP_SST;
> +
> + if (sink_mst_mode == DRM_DP_SST_SIDEBAND_MSG)
> + return DRM_DP_SST;
> +
> + return sink_mst_mode;
> +}
> +
> static bool
> intel_dp_mst_detect(struct intel_dp *intel_dp)
> {
> @@ -4025,12 +4043,7 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
>
> sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
>
> - if (i915->display.params.enable_dp_mst &&
> - intel_dp_mst_source_support(intel_dp) &&
> - sink_mst_mode == DRM_DP_MST)
> - mst_detect = DRM_DP_MST;
> - else
> - mst_detect = DRM_DP_SST;
> + mst_detect = intel_dp_mst_mode_choose(intel_dp, sink_mst_mode);
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s -> enable: %s\n",
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 2/6] drm/i915/mst: improve debug logging of DP MST mode detect
On Tue, Feb 13, 2024 at 01:30:57PM +0200, Jani Nikula wrote:
> Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
> detect debug logging there. Debug log the sink's MST capability,
> including single-stream sideband messaging support, and the decision
> whether to enable MST mode or not. Do this regardless of whether we're
> actually enabling MST or not.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 45 +
> 1 file changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a1c304f451bd..944f566525dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4007,31 +4007,48 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> intel_dp->downstream_ports) == 0;
> }
>
> +static const char *intel_dp_mst_mode_str(enum drm_dp_mst_mode mst_mode)
> +{
> + if (mst_mode == DRM_DP_SST_SIDEBAND_MSG)
> + return "single-stream sideband messaging";
> + else
> + return str_yes_no(mst_mode == DRM_DP_MST);
I wonder if this should also just say "sst"/"mst"/"sst sideband" etc.
Shrug.
Reviewed-by: Ville Syrjälä
> +}
> +
> static bool
> -intel_dp_can_mst(struct intel_dp *intel_dp)
> +intel_dp_mst_detect(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + enum drm_dp_mst_mode sink_mst_mode;
> + enum drm_dp_mst_mode mst_detect;
> +
> + sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> +
> + if (i915->display.params.enable_dp_mst &&
> + intel_dp_mst_source_support(intel_dp) &&
> + sink_mst_mode == DRM_DP_MST)
> + mst_detect = DRM_DP_MST;
> + else
> + mst_detect = DRM_DP_SST;
>
> - return i915->display.params.enable_dp_mst &&
> - intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DRM_DP_MST;
> + drm_dbg_kms(>drm,
> + "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s -> enable: %s\n",
> + encoder->base.base.id, encoder->base.name,
> + str_yes_no(intel_dp_mst_source_support(intel_dp)),
> + intel_dp_mst_mode_str(sink_mst_mode),
> + str_yes_no(i915->display.params.enable_dp_mst),
> + intel_dp_mst_mode_str(mst_detect));
> +
> + return mst_detect != DRM_DP_SST;
> }
>
> static void
> intel_dp_configure_mst(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_encoder *encoder =
> - _to_dig_port(intel_dp)->base;
> bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DRM_DP_MST;
>
> - drm_dbg_kms(>drm,
> - "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> - encoder->base.base.id, encoder->base.name,
> - str_yes_no(intel_dp_mst_source_support(intel_dp)),
> - str_yes_no(sink_can_mst),
> - str_yes_no(i915->display.params.enable_dp_mst));
> -
> if (!intel_dp_mst_source_support(intel_dp))
> return;
>
> @@ -5390,7 +5407,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> connector_status_connected : connector_status_disconnected;
> }
>
> - if (intel_dp_can_mst(intel_dp))
> + if (intel_dp_mst_detect(intel_dp))
> return connector_status_connected;
>
> /* If no HPD, poke DDC gently */
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 1/6] drm/mst: read sideband messaging cap
On Tue, Feb 13, 2024 at 01:30:56PM +0200, Jani Nikula wrote:
> Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST
> with sideband messaging", or "MST". Modify all call sites to take the
> new return value into account.
>
> v2:
> - Rename enumerators (Ville)
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 23 ++-
> 4 files changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 03d528209426..c193be3577f7 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3608,24 +3608,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const struct
> drm_dp_mst_topology_mgr *mgr,
> EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>
> /**
> - * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> + * drm_dp_read_mst_cap() - Read the sink's MST mode capability
> * @aux: The DP AUX channel to use
> * @dpcd: A cached copy of the DPCD capabilities for this sink
> *
> - * Returns: %True if the sink supports MST, %false otherwise
> + * Returns: enum drm_dp_mst_mode to indicate MST mode capability
> */
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> - const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> u8 mstm_cap;
>
> if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> - return false;
> + return DRM_DP_SST;
>
> if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
> - return false;
> + return DRM_DP_SST;
> +
> + if (mstm_cap & DP_MST_CAP)
> + return DRM_DP_MST;
> +
> + if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
> + return DRM_DP_SST_SIDEBAND_MSG;
>
> - return mstm_cap & DP_MST_CAP;
> + return DRM_DP_SST;
> }
> EXPORT_SYMBOL(drm_dp_read_mst_cap);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5045c34a16be..a1c304f451bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4014,7 +4014,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>
> return i915->display.params.enable_dp_mst &&
> intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DRM_DP_MST;
> }
>
> static void
> @@ -4023,7 +4023,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder =
> _to_dig_port(intel_dp)->base;
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DRM_DP_MST;
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7de7707ec6a8..fb06ee17d9e5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
> *nv_connector,
> if (nouveau_mst) {
> mstm = outp->dp.mstm;
> if (mstm)
> - mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
> + mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd) ==
> DRM_DP_MST;
> }
>
> if (nouveau_dp_has_sink_count(connector, outp)) {
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 9b19d8bd520a..3c9e128c444a 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -818,7 +818,28 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
>
> -bool drm_dp_read_mst_cap(struct d
Re: [PATCH] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
gt; - sdp->db[17] = 0x3;
> >> - break;
> >> - case 16:
> >> - sdp->db[17] = 0x4;
> >> - break;
> >> - default:
> >> - MISSING_CASE(vsc->bpc);
> >> - break;
> >> - }
> >> - /* Dynamic Range and Component Bit Depth */
> >> - if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
> >> - sdp->db[17] |= 0x80; /* DB17[7] */
> >> -
> >> - /* Content Type */
> >> - sdp->db[18] = vsc->content_type & 0x7;
> >> -
> >> -out:
> >> - return length;
> >> -}
> >> -
> >> static ssize_t
> >> intel_dp_hdr_metadata_infoframe_sdp_pack(struct drm_i915_private *i915,
> >> const struct hdmi_drm_infoframe
> >> *drm_infoframe,
> >> @@ -4269,8 +4202,8 @@ static void intel_write_dp_sdp(struct intel_encoder
> >> *encoder,
> >>
> >> switch (type) {
> >> case DP_SDP_VSC:
> >> - len = intel_dp_vsc_sdp_pack(_state->infoframes.vsc,
> >> ,
> >> - sizeof(sdp));
> >> + len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc,
> >> ,
> >> + sizeof(sdp));
> >> break;
> >> case HDMI_PACKET_TYPE_GAMUT_METADATA:
> >> len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
> >> @@ -4297,7 +4230,7 @@ void intel_write_dp_vsc_sdp(struct intel_encoder
> >> *encoder,
> >> struct dp_sdp sdp = {};
> >> ssize_t len;
> >>
> >> - len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> >> + len = drm_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> >>
> >> if (drm_WARN_ON(_priv->drm, len < 0))
> >> return;
> >> diff --git a/include/drm/display/drm_dp_helper.h
> >> b/include/drm/display/drm_dp_helper.h
> >> index 863b2e7add29..f8db34a2f7a5 100644
> >> --- a/include/drm/display/drm_dp_helper.h
> >> +++ b/include/drm/display/drm_dp_helper.h
> >> @@ -813,4 +813,7 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> >> int bpp_x16, unsigned long flags);
> >> int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
> >>
> >> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> >> + struct dp_sdp *sdp, size_t size);
> >> +
> >> #endif /* _DRM_DP_HELPER_H_ */
> >> --
> >> 2.34.1
> >>
> >
> >
--
Ville Syrjälä
Intel
Re: [PATCH] drm: document userspace expectations around the Colorspace connector property
On Mon, Feb 12, 2024 at 05:50:36PM +0100, Sebastian Wick wrote: > On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote: > > On Fri, 9 Feb 2024 17:53:07 +0100 > > Xaver Hugl wrote: > > > > > Signed-off-by: Xaver Hugl > > > --- > > > drivers/gpu/drm/drm_connector.c | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_connector.c > > > b/drivers/gpu/drm/drm_connector.c > > > index b0516505f7ae..01e13984629b 100644 > > > --- a/drivers/gpu/drm/drm_connector.c > > > +++ b/drivers/gpu/drm/drm_connector.c > > > @@ -2158,6 +2158,14 @@ > > > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); > > > * one supported. Sink supported colorspaces should be retrieved by > > > * userspace from EDID and driver will not explicitly expose them. > > > * > > > + * As userspace can't currently know whether or not the output is > > > using > > > + * RGB or YCC signalling, the driver must translate properties to > > > their > > > + * relevant RGB or YCC counterparts, depending on the actually used > > > + * signalling. Property values that are only valid for either YCC or > > > RGB > > > + * and have no equivalent for the other signalling type must not be > > > + * exposed as supported, unless the driver can guarantee it never > > > uses > > > + * the signalling that doesn't match the property. > > > + * > > > * Basically the expectation from userspace is: > > > * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > > *colorspace > > > > While this addition is good, I have another question: > > > > Does "Colorspace" property choose also the RGB->YCbCr matrix that the > > driver will use when it happens to use YCbCr signalling? > > > > So far we have only been talking about the primaries and white point. > > Uh, yeah, good point. The InfoFrames do affect both the YCbCr conversion > and the transfer characteristics that the sink expects. Drivers should > do the RGB to YCbCr conversion with the new matrix. I think (and very > much hope) that drivers don't rely on the TF for any internal processing > but if they did, they also should use the one the sink expects. What we need is: - list of the property values that are still allowd (the ones that still make sense with the changed semantics) - mark all the other ones as deprecated - filter/reject the deprecated values when creating the property - document each valid enum value fully (for both RGB and YCbCr output): * what exacly is signalled to the sink via infoframe/msa/vsc sdp * what processing is the driver expected to perform on the actual data -- Ville Syrjälä Intel
Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick > > > > > > > > > wrote: > > > > > > > > > > > > /** > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > * > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full vs > > > > > > > > > > > > Limited) used. > > > > > > > > > > > > + * Infoframes will be generated according to that > > > > > > > > > > > > value. > > > > > > > > > > > > + * > > > > > > > > > > > > + * The value of this property can be one of the > > > > > > > > > > > > following: > > > > > > > > > > > > + * > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > + * RGB Range is selected automatically > > > > > > > > > > > > based on the mode > > > > > > > > > > > > + * according to the HDMI specifications. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Full: > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > + * Limited RGB Range is forced. Unlike > > > > > > > > > > > > the name suggests, > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. > > > > > > > > > > > There might be two > > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color > > > > > > > > > > > pipeline processing > > > > > > > > > > > such that a full-range input to the CRTC is converted to > > > > > > > > > > > either full- or > > > > > > > > > > > limited-range, depending on what the monitor is supposed > > > > > > > > > > > to accept. > > > > > > > > > > > > > > > > > > > > > > When automatic is selected, does that mean that there is > > > > > > > > > > > no signalling, > > > > > > > > > > > or that the signalling matc
Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote: > > > > > > > > > > /** > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > * > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > + * Indicates the RGB Quantization Range (Full vs > > > > > > > > > > Limited) used. > > > > > > > > > > + * Infoframes will be generated according to that > > > > > > > > > > value. > > > > > > > > > > + * > > > > > > > > > > + * The value of this property can be one of the > > > > > > > > > > following: > > > > > > > > > > + * > > > > > > > > > > + * Automatic: > > > > > > > > > > + * RGB Range is selected automatically based > > > > > > > > > > on the mode > > > > > > > > > > + * according to the HDMI specifications. > > > > > > > > > > + * > > > > > > > > > > + * Full: > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > + * > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > + * Limited RGB Range is forced. Unlike the > > > > > > > > > > name suggests, > > > > > > > > > > + * this works for any number of > > > > > > > > > > bits-per-component. > > > > > > > > > > + * > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. There > > > > > > > > > might be two > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color pipeline > > > > > > > > > processing > > > > > > > > > such that a full-range input to the CRTC is converted to > > > > > > > > > either full- or > > > > > > > > > limited-range, depending on what the monitor is supposed to > > > > > > > > > accept. > > > > > > > > > > > > > > > > > > When automatic is selected, does that mean that there is no > > > > > > > > > signalling, > > > > > > > > > or that the signalling matches what the monitor is supposed > > > > > > > > > to accept > > > > > > > > > according to the spec? Also, is this really HDMI specific? > > > > > > > > > > > > > > > > > > When full or limited is selected and the monitor doesn't > > > > > > > > > support the > > > > > > > > > signalling, what happens? > > > > > > > > > > > > > > > > Forgot to mention: user-space still has no control over RGB vs > > > > > > > > YCbCr on > > > > > > > > the cable, so is this only affec
Re: [RFC 2/4] drm/i915/dp: refactor DP MST detection and configuration
On Mon, Feb 12, 2024 at 05:25:43PM +0200, Jani Nikula wrote:
> On Fri, 02 Feb 2024, Ville Syrjälä wrote:
> > On Fri, Feb 02, 2024 at 04:05:32PM +0200, Jani Nikula wrote:
> >> Currently we've split MST capability detection in two places,
> >> intel_dp_can_mst() and intel_dp_configure_mst(). They check essentially
> >> the same things.
> >>
> >> Move bulk of the work, including logging, to intel_dp_can_mst() and
> >> rename it intel_dp_mst_detect(). Set intel_dp->is_mst there to avoid
> >> duplicate work.
> >
> > This seems confusing. is_mst is supposed to reflect the state
> > of the topology manager, nothing more.
>
> We'll, that's still exactly what we're going to set the topology manager
> state to. It's just that now we figure it out just a little earlier, so
> we don't have to duplicate the dpcd reads and logic to two places.
That may be desiresable, but I don't think the current is_mst
flag is really the correct thing to track that. We now set it
somewhere deep down in the detect path wihtout configuring
the mst manager to match, but we clear it much higher up
and there we do assume it 100% matches the state of the topology
manager.
Eg. what happens now if we were previosuly using MST, and now
intel_dp_mst_detect() clears the flag? It looks to me like
we're going to completely forget to call
drm_dp_mst_topology_mgr_set_mst(...,false).
>
> BR,
> Jani.
>
>
> >
> >>
> >> Rename intel_dp_configure_mst() to intel_dp_mst_configure(), and only
> >> set the topology manager state there.
> >>
> >> The main functional difference is that the DP_MSTM_CAP DPCD register is
> >> now only read once at detect, unconditionally, and the MST support is
> >> always logged. Everything else should remain the same.
> >>
> >> Cc: Arun R Murthy
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dp.c | 36 ++---
> >> 1 file changed, 14 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 7af09f2c008d..e0b8ee6bde79 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -4004,23 +4004,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >> intel_dp->downstream_ports) == 0;
> >> }
> >>
> >> -static bool
> >> -intel_dp_can_mst(struct intel_dp *intel_dp)
> >> +static bool intel_dp_mst_detect(struct intel_dp *intel_dp)
> >> {
> >>struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> >> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> >> == DP_MST_CAPABLE;
> >>
> >> - return i915->display.params.enable_dp_mst &&
> >> + intel_dp->is_mst = i915->display.params.enable_dp_mst &&
> >>intel_dp_mst_source_support(intel_dp) &&
> >> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> >> DP_MST_CAPABLE;
> >> -}
> >> -
> >> -static void
> >> -intel_dp_configure_mst(struct intel_dp *intel_dp)
> >> -{
> >> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >> - struct intel_encoder *encoder =
> >> - _to_dig_port(intel_dp)->base;
> >> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> >> == DP_MST_CAPABLE;
> >> + sink_can_mst;
> >>
> >>drm_dbg_kms(>drm,
> >>"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> >> %s\n",
> >> @@ -4029,14 +4021,14 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> >>str_yes_no(sink_can_mst),
> >>str_yes_no(i915->display.params.enable_dp_mst));
> >>
> >> - if (!intel_dp_mst_source_support(intel_dp))
> >> - return;
> >> -
> >> - intel_dp->is_mst = sink_can_mst &&
> >> - i915->display.params.enable_dp_mst;
> >> + return intel_dp->is_mst;
> >> +}
> >>
> >> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> >> - intel_dp->is_mst);
> >> +static void intel_dp_mst_configure(struct intel_dp *intel_dp)
> >> +{
>
Re: [RFC 4/4] drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
On Mon, Feb 12, 2024 at 05:30:40PM +0200, Jani Nikula wrote: > On Fri, 02 Feb 2024, Ville Syrjälä wrote: > > On Fri, Feb 02, 2024 at 04:05:34PM +0200, Jani Nikula wrote: > >> If the sink supports 128b/132b and single-stream sideband messaging, > >> enable MST mode. > >> > >> With this, the topology manager will still write DP_MSTM_CTRL, which > >> should be ignored by the sink. In the future, > >> drm_dp_mst_topology_mgr_set_mst() bool mst_state parameter should > >> probably be turned into an enum drm_dp_mst_mode mst_mode parameter. > > > > Rather I'd say the topology manager should stop concerning itself > > with the MST enable bit and just frob the sideband enable bit. > > The MST enable bit should be configured at modeset time to > > reflect whether we're about to transmit in MST or SST mode. > > Are you suggesting the driver should write the MST vs. SST mode in > DP_MSTM_CTRL? Either that or there needs to be a function provided by the topology manager that gets called at modeset time to configure it. I don't recall when exactly it should be configured according the DP spec. > > I worry a bit about the rmw on DPCD regs. The topology manager only does > writes. > > BR, > Jani. > > > > > > > > >> > >> Cc: Arun R Murthy > >> Cc: Ville Syrjälä > >> Signed-off-by: Jani Nikula > >> --- > >> drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > >> b/drivers/gpu/drm/i915/display/intel_dp.c > >> index 4dd9c50226d1..16130e87dc23 100644 > >> --- a/drivers/gpu/drm/i915/display/intel_dp.c > >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c > >> @@ -4020,7 +4020,9 @@ static bool intel_dp_mst_detect(struct intel_dp > >> *intel_dp) > >> > >>intel_dp->is_mst = i915->display.params.enable_dp_mst && > >>intel_dp_mst_source_support(intel_dp) && > >> - sink_mst_mode == DP_MST_CAPABLE; > >> + (sink_mst_mode == DP_MST_CAPABLE || > >> + (sink_mst_mode == DP_MST_SIDEBAND_MSG && > >> +intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & > >> DP_CAP_ANSI_128B132B)); > >> > >>drm_dbg_kms(>drm, > >>"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam: > >> %s -> enable: %s\n", > >> -- > >> 2.39.2 > > -- > Jani Nikula, Intel -- Ville Syrjälä Intel
Re: [PATCH 02/19] drm/dp: Add support for DP tunneling
On Wed, Feb 07, 2024 at 11:02:27PM +0200, Imre Deak wrote:
> On Wed, Feb 07, 2024 at 10:48:53PM +0200, Imre Deak wrote:
> > On Wed, Feb 07, 2024 at 10:02:18PM +0200, Ville Syrjälä wrote:
> > > > [...]
> > > > +static int
> > > > +drm_dp_tunnel_atomic_check_group_bw(struct drm_dp_tunnel_group_state
> > > > *new_group_state,
> > > > + u32 *failed_stream_mask)
> > > > +{
> > > > + struct drm_dp_tunnel_group *group =
> > > > to_group(new_group_state->base.obj);
> > > > + struct drm_dp_tunnel_state *new_tunnel_state;
> > > > + u32 group_stream_mask = 0;
> > > > + int group_bw = 0;
> > > > +
> > > > + for_each_tunnel_state(new_group_state, new_tunnel_state) {
> > > > + struct drm_dp_tunnel *tunnel =
> > > > new_tunnel_state->tunnel_ref.tunnel;
> > > > + int max_dprx_bw = get_max_dprx_bw(tunnel);
> > > > + int tunnel_bw =
> > > > drm_dp_tunnel_atomic_get_tunnel_bw(new_tunnel_state);
> > > > +
> > > > + tun_dbg(tunnel,
> > > > + "%sRequired %d/%d Mb/s total for tunnel.\n",
> > > > + tunnel_bw > max_dprx_bw ? "Not enough BW: " :
> > > > "",
> > > > + DPTUN_BW_ARG(tunnel_bw),
> > > > + DPTUN_BW_ARG(max_dprx_bw));
> > > > +
> > > > + if (tunnel_bw > max_dprx_bw) {
> > >
> > > I'm a bit confused why we're checking this here. Aren't we already
> > > checking this somewhere else?
> >
> > Ah, yes this should be checked already by the encoder compute config +
> > the MST link BW check. It can be removed, thanks.
>
> Though neither of that is guaranteed for drivers in general, so
> shouldn't it be here still?
I suppose there isn't any real harm in doing it here too.
>
> > > > + *failed_stream_mask =
> > > > new_tunnel_state->stream_mask;
> > > > + return -ENOSPC;
> > > > + }
> > > > +
> > > > + group_bw += min(roundup(tunnel_bw,
> > > > tunnel->bw_granularity),
> > > > + max_dprx_bw);
> > > > + group_stream_mask |= new_tunnel_state->stream_mask;
> > > > + }
> > > > +
> > > > + tun_grp_dbg(group,
> > > > + "%sRequired %d/%d Mb/s total for tunnel group.\n",
> > > > + group_bw > group->available_bw ? "Not enough BW: "
> > > > : "",
> > > > + DPTUN_BW_ARG(group_bw),
> > > > + DPTUN_BW_ARG(group->available_bw));
> > > > +
> > > > + if (group_bw > group->available_bw) {
> > > > + *failed_stream_mask = group_stream_mask;
> > > > + return -ENOSPC;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
--
Ville Syrjälä
Intel
Re: [PATCH 02/19] drm/dp: Add support for DP tunneling
On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> +static char yes_no_chr(int val)
> +{
> + return val ? 'Y' : 'N';
> +}
We have str_yes_no() already.
v> +
> +#define SKIP_DPRX_CAPS_CHECK BIT(0)
> +#define ALLOW_ALLOCATED_BW_CHANGEBIT(1)
> +
> +static bool tunnel_regs_are_valid(struct drm_dp_tunnel_mgr *mgr,
> + const struct drm_dp_tunnel_regs *regs,
> + unsigned int flags)
> +{
> + int drv_group_id = tunnel_reg_drv_group_id(regs);
> + bool check_dprx = !(flags & SKIP_DPRX_CAPS_CHECK);
> + bool ret = true;
> +
> + if (!tunnel_reg_bw_alloc_supported(regs)) {
> + if (tunnel_group_id(drv_group_id)) {
> + drm_dbg_kms(mgr->dev,
> + "DPTUN: A non-zero group ID is only allowed
> with BWA support\n");
> + ret = false;
> + }
> +
> + if (tunnel_reg(regs, DP_ALLOCATED_BW)) {
> + drm_dbg_kms(mgr->dev,
> + "DPTUN: BW is allocated without BWA
> support\n");
> + ret = false;
> + }
> +
> + return ret;
> + }
> +
> + if (!tunnel_group_id(drv_group_id)) {
> + drm_dbg_kms(mgr->dev,
> + "DPTUN: BWA support requires a non-zero group
> ID\n");
> + ret = false;
> + }
> +
> + if (check_dprx && hweight8(tunnel_reg_max_dprx_lane_count(regs)) != 1) {
> + drm_dbg_kms(mgr->dev,
> + "DPTUN: Invalid DPRX lane count: %d\n",
> + tunnel_reg_max_dprx_lane_count(regs));
> +
> + ret = false;
> + }
> +
> + if (check_dprx && !tunnel_reg_max_dprx_rate(regs)) {
> + drm_dbg_kms(mgr->dev,
> + "DPTUN: DPRX rate is 0\n");
> +
> + ret = false;
> + }
> +
> + if (tunnel_reg(regs, DP_ALLOCATED_BW) > tunnel_reg(regs,
> DP_ESTIMATED_BW)) {
> + drm_dbg_kms(mgr->dev,
> + "DPTUN: Allocated BW %d > estimated BW %d Mb/s\n",
> + DPTUN_BW_ARG(tunnel_reg(regs, DP_ALLOCATED_BW) *
> + tunnel_reg_bw_granularity(regs)),
> + DPTUN_BW_ARG(tunnel_reg(regs, DP_ESTIMATED_BW) *
> + tunnel_reg_bw_granularity(regs)));
> +
> + ret = false;
> + }
> +
> + return ret;
> +}
> +
> +static bool tunnel_info_changes_are_valid(struct drm_dp_tunnel *tunnel,
> + const struct drm_dp_tunnel_regs *regs,
> + unsigned int flags)
> +{
> + int new_drv_group_id = tunnel_reg_drv_group_id(regs);
> + bool ret = true;
> +
> + if (tunnel->bw_alloc_supported != tunnel_reg_bw_alloc_supported(regs)) {
> + tun_dbg(tunnel,
> + "BW alloc support has changed %c -> %c\n",
> + yes_no_chr(tunnel->bw_alloc_supported),
> + yes_no_chr(tunnel_reg_bw_alloc_supported(regs)));
> +
> + ret = false;
> + }
> +
> + if (tunnel->group->drv_group_id != new_drv_group_id) {
> + tun_dbg(tunnel,
> + "Driver/group ID has changed %d:%d:* -> %d:%d:*\n",
> + tunnel_group_drv_id(tunnel->group->drv_group_id),
> + tunnel_group_id(tunnel->group->drv_group_id),
> + tunnel_group_drv_id(new_drv_group_id),
> + tunnel_group_id(new_drv_group_id));
> +
> + ret = false;
> + }
> +
> + if (!tunnel->bw_alloc_supported)
> + return ret;
> +
> + if (tunnel->bw_granularity != tunnel_reg_bw_granularity(regs)) {
> + tun_dbg(tunnel,
> + "BW granularity has changed: %d -> %d Mb/s\n",
> + DPTUN_BW_ARG(tunnel->bw_granularity),
> + DPTUN_BW_ARG(tunnel_reg_bw_granularity(regs)));
> +
> + ret = false;
> + }
> +
> + /*
> + * On some devices at least the BW alloc mode enabled status is always
> + * reported as 0, so skip checking that here.
> + */
So it's reported as supported and we enable it, but it's never
reported back as being enabled?
> +
> + if (!(flags & ALLOW_ALLOCATED_BW_CHANGE) &&
> + tunnel->allocated_bw !=
> + tunnel_reg(regs, DP_ALLOCATED_BW) * tunnel->bw_granularity) {
> + tun_dbg(tunnel,
> + "Allocated BW has changed: %d -> %d Mb/s\n",
> + DPTUN_BW_ARG(tunnel->allocated_bw),
> + DPTUN_BW_ARG(tunnel_reg(regs, DP_ALLOCATED_BW) *
> tunnel->bw_granularity));
> +
> + ret = false;
> + }
> +
> + return ret;
> +}
> +
> +static int
> +read_and_verify_tunnel_regs(struct drm_dp_tunnel *tunnel,
> + struct
Re: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state computation
On Tue, Jan 23, 2024 at 12:28:45PM +0200, Imre Deak wrote:
> Compute the BW required through a DP tunnel on links with such tunnels
> detected and add the corresponding atomic state during a modeset.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 +
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 78dfe8be6031d..6968fdb7ffcdf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2880,6 +2880,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> struct drm_connector_state *conn_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> to_intel_atomic_state(conn_state->state);
> struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> const struct drm_display_mode *fixed_mode;
> @@ -2980,6 +2981,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
> intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config,
> conn_state);
>
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> + pipe_config);
Error handling seems awol?
> +
> return 0;
> }
>
> @@ -6087,6 +6091,15 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
> return ret;
> }
>
> + if (!intel_connector_needs_modeset(state, conn))
> + return 0;
> +
> + ret = intel_dp_tunnel_atomic_check_state(state,
> + intel_dp,
> + intel_conn);
> + if (ret)
> + return ret;
> +
> /*
>* We don't enable port sync on BDW due to missing w/as and
>* due to not having adjusted the modeset sequence appropriately.
> @@ -6094,9 +6107,6 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
> if (DISPLAY_VER(dev_priv) < 9)
> return 0;
>
> - if (!intel_connector_needs_modeset(state, conn))
> - return 0;
> -
> if (conn->has_tile) {
> ret = intel_modeset_tile_group(state, conn->tile_group->id);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 520393dc8b453..cbfab3173b9ef 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -42,6 +42,7 @@
> #include "intel_dp.h"
> #include "intel_dp_hdcp.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_hdcp.h"
> #include "intel_hotplug.h"
> @@ -523,6 +524,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> struct drm_connector_state *conn_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> to_intel_atomic_state(conn_state->state);
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct intel_dp *intel_dp = _mst->primary->dp;
> const struct intel_connector *connector =
> @@ -619,6 +621,9 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>
> intel_psr_compute_config(intel_dp, pipe_config, conn_state);
>
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> + pipe_config);
> +
> return 0;
> }
>
> @@ -876,6 +881,14 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
> if (ret)
> return ret;
>
> + if (intel_connector_needs_modeset(state, connector)) {
> + ret = intel_dp_tunnel_atomic_check_state(state,
> +
> intel_connector->mst_port,
> + intel_connector);
> + if (ret)
> + return ret;
> + }
> +
> return drm_dp_atomic_release_time_slots(>base,
>
> _connector->mst_port->mst_mgr,
> intel_connector->port);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH 11/19] drm/i915/dp: Add support for DP tunnel BW allocation
gt; +}
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_tunnel.h
> b/drivers/gpu/drm/i915/display/intel_dp_tunnel.h
> new file mode 100644
> index 0..bedba3ba9ad8d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_dp_tunnel.h
> @@ -0,0 +1,131 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2023 Intel Corporation
> + */
> +
> +#ifndef __INTEL_DP_TUNNEL_H__
> +#define __INTEL_DP_TUNNEL_H__
> +
> +#include
> +#include
> +
> +struct drm_i915_private;
> +struct drm_connector_state;
> +struct drm_modeset_acquire_ctx;
> +
> +struct intel_atomic_state;
> +struct intel_connector;
> +struct intel_crtc;
> +struct intel_crtc_state;
> +struct intel_dp;
> +struct intel_encoder;
> +struct intel_link_bw_limits;
> +
> +#if defined(CONFIG_DRM_I915_DP_TUNNEL) && defined(I915)
> +
> +int intel_dp_tunnel_detect(struct intel_dp *intel_dp, struct
> drm_modeset_acquire_ctx *ctx);
> +void intel_dp_tunnel_disconnect(struct intel_dp *intel_dp);
> +void intel_dp_tunnel_destroy(struct intel_dp *intel_dp);
> +void intel_dp_tunnel_resume(struct intel_dp *intel_dp, bool dpcd_updated);
> +void intel_dp_tunnel_suspend(struct intel_dp *intel_dp);
> +
> +bool intel_dp_tunnel_bw_alloc_is_enabled(struct intel_dp *intel_dp);
> +
> +void
> +intel_dp_tunnel_atomic_cleanup_inherited_state(struct intel_atomic_state
> *state);
> +
> +void intel_dp_tunnel_atomic_compute_stream_bw(struct intel_atomic_state
> *state,
> + struct intel_dp *intel_dp,
> + const struct intel_connector
> *connector,
> + struct intel_crtc_state
> *crtc_state);
> +
> +int intel_dp_tunnel_atomic_add_state_for_crtc(struct intel_atomic_state
> *state,
> + struct intel_crtc *crtc);
> +int intel_dp_tunnel_atomic_check_link(struct intel_atomic_state *state,
> + struct intel_link_bw_limits *limits);
> +int intel_dp_tunnel_atomic_check_state(struct intel_atomic_state *state,
> +struct intel_dp *intel_dp,
> +struct intel_connector *connector);
> +void intel_dp_tunnel_atomic_alloc_bw(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *new_crtc_state,
> + const struct drm_connector_state
> *new_conn_state);
> +void intel_dp_tunnel_atomic_free_bw(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *old_crtc_state,
> + const struct drm_connector_state
> *old_conn_state);
> +
> +int intel_dp_tunnel_mgr_init(struct drm_i915_private *i915);
> +void intel_dp_tunnel_mgr_cleanup(struct drm_i915_private *i915);
> +
> +#else
> +
> +static inline int
> +intel_dp_tunnel_detect(struct intel_dp *intel_dp, struct
> drm_modeset_acquire_ctx *ctx)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void intel_dp_tunnel_disconnect(struct intel_dp *intel_dp) {}
> +static inline void intel_dp_tunnel_destroy(struct intel_dp *intel_dp) {}
> +static inline void intel_dp_tunnel_resume(struct intel_dp *intel_dp, bool
> dpcd_updated) {}
> +static inline void intel_dp_tunnel_suspend(struct intel_dp *intel_dp) {}
> +
> +static inline bool intel_dp_tunnel_bw_alloc_is_enabled(struct intel_dp
> *intel_dp)
> +{
> + return false;
> +}
> +
> +static inline void
> +intel_dp_tunnel_atomic_cleanup_inherited_state(struct intel_atomic_state
> *state) {}
> +
> +static inline void
> +intel_dp_tunnel_atomic_compute_stream_bw(struct intel_atomic_state *state,
> + struct intel_dp *intel_dp,
> + const struct intel_connector
> *connector,
> + struct intel_crtc_state *crtc_state) {}
> +
> +static inline int
> +intel_dp_tunnel_atomic_add_state_for_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + return 0;
> +}
> +
> +static inline int
> +intel_dp_tunnel_atomic_check_link(struct intel_atomic_state *state,
> + struct intel_link_bw_limits *limits)
> +{
> + return 0;
> +}
> +
> +static inline int
> +intel_dp_tunnel_atomic_check_state(struct intel_atomic_state *state,
> +struct intel_dp *intel_dp,
> +struct intel_connector *connector)
> +{
> + return 0;
> +}
> +
> +static inline void
> +intel_dp_tunnel_atomic_alloc_bw(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state *new_crtc_state,
> + const struct drm_connector_state
> *new_conn_state) {}
> +static inline void
> +intel_dp_tunnel_atomic_free_bw(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *old_crtc_state,
> +const struct drm_connector_state
> *old_conn_state) {}
> +
> +static inline int
> +intel_dp_tunnel_mgr_init(struct drm_i915_private *i915)
> +{
> + return 0;
> +}
> +
> +static inline void intel_dp_tunnel_mgr_cleanup(struct drm_i915_private
> *i915) {}
> +
> +#endif /* CONFIG_DRM_I915_DP_TUNNEL */
> +
> +#endif /* __INTEL_DP_TUNNEL_H__ */
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH 11/19] drm/i915/dp: Add support for DP tunnel BW allocation
On Tue, Jan 23, 2024 at 12:28:42PM +0200, Imre Deak wrote:
> +static int check_inherited_tunnel_state(struct intel_atomic_state *state,
> + struct intel_dp *intel_dp,
> + const struct
> intel_digital_connector_state *old_conn_state)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + const struct intel_connector *connector =
> + to_intel_connector(old_conn_state->base.connector);
> + struct intel_crtc *old_crtc;
> + const struct intel_crtc_state *old_crtc_state;
> +
> + /*
> + * If a BWA tunnel gets detected only after the corresponding
> + * connector got enabled already without a BWA tunnel, or a different
> + * BWA tunnel (which was removed meanwhile) the old CRTC state won't
> + * contain the state of the current tunnel. This tunnel still has a
> + * reserved BW, which needs to be released, add the state for such
> + * inherited tunnels separately only to this atomic state.
> + */
> + if (!intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + return 0;
> +
> + if (!old_conn_state->base.crtc)
> + return 0;
> +
> + old_crtc = to_intel_crtc(old_conn_state->base.crtc);
> + old_crtc_state = intel_atomic_get_old_crtc_state(state, old_crtc);
> +
> + if (!old_crtc_state->hw.active ||
> + old_crtc_state->dp_tunnel_ref.tunnel == intel_dp->tunnel)
> + return 0;
> +
> + drm_dbg_kms(>drm,
> + "[DPTUN %s][CONNECTOR:%d:%s][ENCODER:%d:%s][CRTC:%d:%s]
> Adding state for inherited tunnel %p\n",
> + drm_dp_tunnel_name(intel_dp->tunnel),
> + connector->base.base.id,
> + connector->base.name,
> + encoder->base.base.id,
> + encoder->base.name,
> + old_crtc->base.base.id,
> + old_crtc->base.name,
> + intel_dp->tunnel);
> +
> + return add_inherited_tunnel_state(state, intel_dp->tunnel, old_crtc);
I still strongly dislike this "tunnels are magically created by detect
behind our back" approach. IMO in an ideal world we'd only ever create the
tunnels during modeset/sanitize. What was the reason that didn't work again?
I think you explained it to me in person at least once already, but can't
remember anymore...
--
Ville Syrjälä
Intel
Re: [PATCH 02/19] drm/dp: Add support for DP tunneling
On Mon, Feb 05, 2024 at 07:15:17PM +0200, Imre Deak wrote:
> On Mon, Feb 05, 2024 at 06:13:30PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 31, 2024 at 08:49:16PM +0200, Imre Deak wrote:
> > > On Wed, Jan 31, 2024 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > > > > +static void untrack_tunnel_ref(struct drm_dp_tunnel *tunnel,
> > > > > +struct ref_tracker **tracker)
> > > > > +{
> > > > > + ref_tracker_free(>group->mgr->ref_tracker,
> > > > > + tracker);
> > > > > +}
> > > > > +
> > > > > +struct drm_dp_tunnel *
> > > > > +drm_dp_tunnel_get_untracked(struct drm_dp_tunnel *tunnel)
> > > > > +{
> > > > > + track_tunnel_ref(tunnel, NULL);
> > > > > +
> > > > > + return tunnel_get(tunnel);
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_dp_tunnel_get_untracked);
> > > >
> > > > Why do these exist?
> > >
> > > They implement drm_dp_tunnel_get()/put() if
> > > CONFIG_DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE=n.
> >
> > Why does that kind of irrelevant detail need to be visible
> > in the exported api?
>
> In non-debug builds the ref_tracker object isn't needed and so
> drm_dp_tunnel_ref won't contain a pointer to it either.
Since it's just a pointer I don't see much point in making
things more complicated by leaving it out.
> drm_dp_tunnel_get/put_untracked() provide a way to get/put a tunnel
> reference without having to pass a ref_tracker pointer.
>
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
Re: [PATCH 02/19] drm/dp: Add support for DP tunneling
On Wed, Jan 31, 2024 at 08:49:16PM +0200, Imre Deak wrote:
> On Wed, Jan 31, 2024 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > > +static void untrack_tunnel_ref(struct drm_dp_tunnel *tunnel,
> > > +struct ref_tracker **tracker)
> > > +{
> > > + ref_tracker_free(>group->mgr->ref_tracker,
> > > + tracker);
> > > +}
> > > +
> > > +struct drm_dp_tunnel *
> > > +drm_dp_tunnel_get_untracked(struct drm_dp_tunnel *tunnel)
> > > +{
> > > + track_tunnel_ref(tunnel, NULL);
> > > +
> > > + return tunnel_get(tunnel);
> > > +}
> > > +EXPORT_SYMBOL(drm_dp_tunnel_get_untracked);
> >
> > Why do these exist?
>
> They implement drm_dp_tunnel_get()/put() if
> CONFIG_DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE=n.
Why does that kind of irrelevant detail need to be visible
in the exported api?
--
Ville Syrjälä
Intel
Re: [PATCH 12/19] drm/i915/dp: Add DP tunnel atomic state and check BW limit
can be safely duplicated. For now, > @@ -5374,6 +5389,10 @@ static int intel_modeset_pipe(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_add_state_for_crtc(state, crtc); > + if (ret) > + return ret; > + > ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c > b/drivers/gpu/drm/i915/display/intel_link_bw.c > index 9c6d35a405a18..5b539ba996ddf 100644 > --- a/drivers/gpu/drm/i915/display/intel_link_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c > @@ -8,6 +8,7 @@ > #include "intel_atomic.h" > #include "intel_display_types.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_fdi.h" > #include "intel_link_bw.h" > > @@ -149,6 +150,10 @@ static int check_all_link_config(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_check_link(state, limits); > + if (ret) > + return ret; > + > ret = intel_fdi_atomic_check_link(state, limits); > if (ret) > return ret; > -- > 2.39.2 -- Ville Syrjälä Intel
Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote: > > > > > > /** > > > > > > * DOC: HDMI connector properties > > > > > > * > > > > > > + * Broadcast RGB > > > > > > + * Indicates the RGB Quantization Range (Full vs Limited) > > > > > > used. > > > > > > + * Infoframes will be generated according to that value. > > > > > > + * > > > > > > + * The value of this property can be one of the following: > > > > > > + * > > > > > > + * Automatic: > > > > > > + * RGB Range is selected automatically based on the > > > > > > mode > > > > > > + * according to the HDMI specifications. > > > > > > + * > > > > > > + * Full: > > > > > > + * Full RGB Range is forced. > > > > > > + * > > > > > > + * Limited 16:235: > > > > > > + * Limited RGB Range is forced. Unlike the name > > > > > > suggests, > > > > > > + * this works for any number of bits-per-component. > > > > > > + * > > > > > > + * Drivers can set up this property by calling > > > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > > > + * > > > > > > > > > > This is a good time to document this in more detail. There might be > > > > > two > > > > > different things being affected: > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > 2. The color pipeline processing > > > > > > > > > > All values of Broadcast RGB always affect the color pipeline > > > > > processing > > > > > such that a full-range input to the CRTC is converted to either full- > > > > > or > > > > > limited-range, depending on what the monitor is supposed to accept. > > > > > > > > > > When automatic is selected, does that mean that there is no > > > > > signalling, > > > > > or that the signalling matches what the monitor is supposed to accept > > > > > according to the spec? Also, is this really HDMI specific? > > > > > > > > > > When full or limited is selected and the monitor doesn't support the > > > > > signalling, what happens? > > > > > > > > Forgot to mention: user-space still has no control over RGB vs YCbCr on > > > > the cable, so is this only affecting RGB? If not, how does it affect > > > > YCbCr? > > > > > > So I dug a bit into both the i915 and vc4 drivers, and it looks like if > > > we're using a YCbCr format, i915 will always use a limited range while > > > vc4 will follow the value of the property. > > > > The property is literally called "Broadcast *RGB*". > > That should explain why it's only affecting RGB. > > Right. And the limited range option is called "Limited 16:235" despite > being usable on bpc > 8 bits. Naming errors occurs, and history happens > to make names inconsistent too, that's fine and not an argument in > itself. > > > Full range YCbCr is a much rarer beast so we've never bothered > > to enable it. > > vc4 supports it. Someone implemented it incorrectly then. > > > Eg. with DP it only became possible with the introduction of the VSC > > SDP (and I don't recall if there's additional capability checks that > > are also required). With DP MSA signalling full range YCbCr is not > > possible at all. > > This is for HDMI only. > > > I don't recall right now what the HDMI requirements are. > > HDMI has supported it for a while, and it's defined (for example) in the > HDMI 1.4 spec in Section 6.6 - Video Quantization Ranges. It supports > limited and full range on both RGB and YCbCr, as long as the EDIDs state > so and the Infoframes signal it. I think a good reason for not using a simple boolean like this YCbCr is that it doesn't cover the color encoding part at all, which is probably more important than the quantization range. So we need a new property anyway. -- Ville Syrjälä Intel
Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Fri, Feb 02, 2024 at 12:20:21PM +0100, Hans Verkuil wrote: > On 02/02/2024 12:04, Jani Nikula wrote: > > On Mon, 15 Jan 2024, Sebastian Wick wrote: > >> On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote: > >>> The i915 driver has a property to force the RGB range of an HDMI output. > >>> The vc4 driver then implemented the same property with the same > >>> semantics. KWin has support for it, and a PR for mutter is also there to > >>> support it. > >>> > >>> Both drivers implementing the same property with the same semantics, > >>> plus the userspace having support for it, is proof enough that it's > >>> pretty much a de-facto standard now and we can provide helpers for it. > >>> > >>> Let's plumb it into the newly created HDMI connector. > >>> > >>> Signed-off-by: Maxime Ripard > > > > [snip] > > > >>> @@ -1655,6 +1678,26 @@ > >>> EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property); > >>> /** > >>> * DOC: HDMI connector properties > >>> * > >>> + * Broadcast RGB > >>> + * Indicates the RGB Quantization Range (Full vs Limited) used. > >>> + * Infoframes will be generated according to that value. > >>> + * > >>> + * The value of this property can be one of the following: > >>> + * > >>> + * Automatic: > >>> + * RGB Range is selected automatically based on the mode > >>> + * according to the HDMI specifications. > >>> + * > >>> + * Full: > >>> + * Full RGB Range is forced. > >>> + * > >>> + * Limited 16:235: > >>> + * Limited RGB Range is forced. Unlike the name suggests, > >>> + * this works for any number of bits-per-component. > >>> + * > >>> + * Drivers can set up this property by calling > >>> + * drm_connector_attach_broadcast_rgb_property(). > >>> + * > >> > >> This is a good time to document this in more detail. There might be two > >> different things being affected: > >> > >> 1. The signalling (InfoFrame/SDP/...) > >> 2. The color pipeline processing > >> > >> All values of Broadcast RGB always affect the color pipeline processing > >> such that a full-range input to the CRTC is converted to either full- or > >> limited-range, depending on what the monitor is supposed to accept. > >> > >> When automatic is selected, does that mean that there is no signalling, > >> or that the signalling matches what the monitor is supposed to accept > >> according to the spec? Also, is this really HDMI specific? > > > > Automatic is based on the mode as described in the specs > > below. Basically certain modes are expected to be broadcast range, and > > others full range. > > > > I don't remember why we don't use the full range if the display > > indicates it supports selectable quantization range in Video > > Capabilities Data Block. It's quite possible there are displays that > > declare support but don't. Cc: Ville. > > I have not seen such displays. Enabling RGB Selectable Quantization Range > is something that a vendor has to do explicitly, so it is reasonable to > expect that it works, otherwise there would be no point to that flag! > > Transmitting full range if possible gives a better picture quality and > so is recommended. > > > > > - HDMI 1.4b section 6.6 Video Quantization Ranges > > > > - HDMI 2.1 section 7.3 Video Quantization Ranges > > > > - DP 2.1 (and earlier) section 5.1.1.1 Video Colorimetry > > > > - CTA-861-H (and earlier) section 5.1 Default Encoding Parameters and > > section 6.4.3 Quantization Range > > Note that CTA-861-H deprecated the use of Default Range in the AVI > InfoFrame, instead the source should always signal limited or full range > in the Q field. Only because the QS=1 is now mandatory IIRC. We do always set Q bit explicitly when QS==1. But yeah, I guess we could always go for full range by default when QS==1. Or maybe we even did that at some point in the past and it broke some things? Can't recall anymore. Anyways, QS=1 being mandatory is a clear improvement in CTA-861, but some other CTA-861 rule updates are more or less pointless as you can't in general detect which version of the spec the sink claims to implement. Eg. we already had cases where following the new CTA-861-F rules for the YQ bit when transmitting RGB broke some displays. And we are now forced to use the presence of HDMI 2.0+ capabilities as a heuristic to detect CTA-851-F+. (see drm_hdmi_avi_infoframe_quant_range()). It's pretty nasty. And I think there is some other infoframe related issue (something to do with VICs IIRC) where we'd need to derive the CTA-861 version eg. from the set of advertised VICs in the EDID. I might have even written some code for that at some point but never finished it. So it's still broken in the current code. Can't recall the specific details right now unfortunately. -- Ville Syrjälä Intel
Re: [RFC 4/4] drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
On Fri, Feb 02, 2024 at 04:05:34PM +0200, Jani Nikula wrote: > If the sink supports 128b/132b and single-stream sideband messaging, > enable MST mode. > > With this, the topology manager will still write DP_MSTM_CTRL, which > should be ignored by the sink. In the future, > drm_dp_mst_topology_mgr_set_mst() bool mst_state parameter should > probably be turned into an enum drm_dp_mst_mode mst_mode parameter. Rather I'd say the topology manager should stop concerning itself with the MST enable bit and just frob the sideband enable bit. The MST enable bit should be configured at modeset time to reflect whether we're about to transmit in MST or SST mode. > > Cc: Arun R Murthy > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 4dd9c50226d1..16130e87dc23 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -4020,7 +4020,9 @@ static bool intel_dp_mst_detect(struct intel_dp > *intel_dp) > > intel_dp->is_mst = i915->display.params.enable_dp_mst && > intel_dp_mst_source_support(intel_dp) && > - sink_mst_mode == DP_MST_CAPABLE; > + (sink_mst_mode == DP_MST_CAPABLE || > + (sink_mst_mode == DP_MST_SIDEBAND_MSG && > + intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & > DP_CAP_ANSI_128B132B)); > > drm_dbg_kms(>drm, > "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam: > %s -> enable: %s\n", > -- > 2.39.2 -- Ville Syrjälä Intel
Re: [RFC 2/4] drm/i915/dp: refactor DP MST detection and configuration
On Fri, Feb 02, 2024 at 04:05:32PM +0200, Jani Nikula wrote:
> Currently we've split MST capability detection in two places,
> intel_dp_can_mst() and intel_dp_configure_mst(). They check essentially
> the same things.
>
> Move bulk of the work, including logging, to intel_dp_can_mst() and
> rename it intel_dp_mst_detect(). Set intel_dp->is_mst there to avoid
> duplicate work.
This seems confusing. is_mst is supposed to reflect the state
of the topology manager, nothing more.
>
> Rename intel_dp_configure_mst() to intel_dp_mst_configure(), and only
> set the topology manager state there.
>
> The main functional difference is that the DP_MSTM_CAP DPCD register is
> now only read once at detect, unconditionally, and the MST support is
> always logged. Everything else should remain the same.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 36 ++---
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7af09f2c008d..e0b8ee6bde79 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4004,23 +4004,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> intel_dp->downstream_ports) == 0;
> }
>
> -static bool
> -intel_dp_can_mst(struct intel_dp *intel_dp)
> +static bool intel_dp_mst_detect(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DP_MST_CAPABLE;
>
> - return i915->display.params.enable_dp_mst &&
> + intel_dp->is_mst = i915->display.params.enable_dp_mst &&
> intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DP_MST_CAPABLE;
> -}
> -
> -static void
> -intel_dp_configure_mst(struct intel_dp *intel_dp)
> -{
> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_encoder *encoder =
> - _to_dig_port(intel_dp)->base;
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DP_MST_CAPABLE;
> + sink_can_mst;
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> @@ -4029,14 +4021,14 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> str_yes_no(sink_can_mst),
> str_yes_no(i915->display.params.enable_dp_mst));
>
> - if (!intel_dp_mst_source_support(intel_dp))
> - return;
> -
> - intel_dp->is_mst = sink_can_mst &&
> - i915->display.params.enable_dp_mst;
> + return intel_dp->is_mst;
> +}
>
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> - intel_dp->is_mst);
> +static void intel_dp_mst_configure(struct intel_dp *intel_dp)
> +{
> + if (intel_dp_mst_source_support(intel_dp))
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> + intel_dp->is_mst);
> }
>
> static bool
> @@ -5387,7 +5379,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> connector_status_connected : connector_status_disconnected;
> }
>
> - if (intel_dp_can_mst(intel_dp))
> + if (intel_dp_mst_detect(intel_dp))
> return connector_status_connected;
>
> /* If no HPD, poke DDC gently */
> @@ -5706,7 +5698,7 @@ intel_dp_detect(struct drm_connector *connector,
>
> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>
> - intel_dp_configure_mst(intel_dp);
> + intel_dp_mst_configure(intel_dp);
>
> /*
>* TODO: Reset link params when switching to MST mode, until MST
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > Hi, > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote: > > > > /** > > > > * DOC: HDMI connector properties > > > > * > > > > + * Broadcast RGB > > > > + * Indicates the RGB Quantization Range (Full vs Limited) used. > > > > + * Infoframes will be generated according to that value. > > > > + * > > > > + * The value of this property can be one of the following: > > > > + * > > > > + * Automatic: > > > > + * RGB Range is selected automatically based on the mode > > > > + * according to the HDMI specifications. > > > > + * > > > > + * Full: > > > > + * Full RGB Range is forced. > > > > + * > > > > + * Limited 16:235: > > > > + * Limited RGB Range is forced. Unlike the name suggests, > > > > + * this works for any number of bits-per-component. > > > > + * > > > > + * Drivers can set up this property by calling > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > + * > > > > > > This is a good time to document this in more detail. There might be two > > > different things being affected: > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > 2. The color pipeline processing > > > > > > All values of Broadcast RGB always affect the color pipeline processing > > > such that a full-range input to the CRTC is converted to either full- or > > > limited-range, depending on what the monitor is supposed to accept. > > > > > > When automatic is selected, does that mean that there is no signalling, > > > or that the signalling matches what the monitor is supposed to accept > > > according to the spec? Also, is this really HDMI specific? > > > > > > When full or limited is selected and the monitor doesn't support the > > > signalling, what happens? > > > > Forgot to mention: user-space still has no control over RGB vs YCbCr on > > the cable, so is this only affecting RGB? If not, how does it affect > > YCbCr? > > So I dug a bit into both the i915 and vc4 drivers, and it looks like if > we're using a YCbCr format, i915 will always use a limited range while > vc4 will follow the value of the property. The property is literally called "Broadcast *RGB*". That should explain why it's only affecting RGB. Full range YCbCr is a much rarer beast so we've never bothered to enable it. Eg. with DP it only became possible with the introduction of the VSC SDP (and I don't recall if there's additional capability checks that are also required). With DP MSA signalling full range YCbCr is not possible at all. I don't recall right now what the HDMI requirements are. -- Ville Syrjälä Intel
Re: [RFC 1/4] drm/mst: read sideband messaging cap
On Fri, Feb 02, 2024 at 04:05:31PM +0200, Jani Nikula wrote:
> Amend drm_dp_read_mst_cap() to return an enum, indicating "none",
> "sideband messaging", or "mst". Modify all call sites to take the new
> return value into account.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 23 ++-
> 4 files changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index f7c6b60629c2..a68a6c8a2495 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3603,24 +3603,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const struct
> drm_dp_mst_topology_mgr *mgr,
> EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>
> /**
> - * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> + * drm_dp_read_mst_cap() - Read the sink's MST mode capability
> * @aux: The DP AUX channel to use
> * @dpcd: A cached copy of the DPCD capabilities for this sink
> *
> - * Returns: %True if the sink supports MST, %false otherwise
> + * Returns: enum drm_dp_mst_mode to indicate MST mode capability
> */
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> - const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> u8 mstm_cap;
>
> if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> - return false;
> + return DP_MST_NONE;
>
> if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
> - return false;
> + return DP_MST_NONE;
> +
> + if (mstm_cap & DP_MST_CAP)
> + return DP_MST_CAPABLE;
> +
> + if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
> + return DP_MST_SIDEBAND_MSG;
>
> - return mstm_cap & DP_MST_CAP;
> + return DP_MST_NONE;
> }
> EXPORT_SYMBOL(drm_dp_read_mst_cap);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ab415f41924d..7af09f2c008d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4011,7 +4011,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>
> return i915->display.params.enable_dp_mst &&
> intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DP_MST_CAPABLE;
> }
>
> static void
> @@ -4020,7 +4020,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder =
> _to_dig_port(intel_dp)->base;
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
> == DP_MST_CAPABLE;
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7de7707ec6a8..d180d22dbab0 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
> *nv_connector,
> if (nouveau_mst) {
> mstm = outp->dp.mstm;
> if (mstm)
> - mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
> + mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd) ==
> DP_MST_CAPABLE;
> }
>
> if (nouveau_dp_has_sink_count(connector, outp)) {
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 9b19d8bd520a..db48016b2aed 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -818,7 +818,28 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
>
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
> +/**
> + *
Re: [PATCH 18/19] drm/i915/dp: Suspend/resume DP tunnels
On Tue, Jan 23, 2024 at 12:28:49PM +0200, Imre Deak wrote:
> Suspend and resume DP tunnels during system suspend/resume, disabling
> the BW allocation mode during suspend, re-enabling it after resume. This
> reflects the link's BW management component (Thunderbolt CM) disabling
> BWA during suspend. Before any BW requests the driver must read the
> sink's DPRX capabilities (since the BW manager requires this
> information, so snoops for it on AUX), so ensure this read takes place.
Isn't that going to screw up the age old problem of .compute_config()
potentially failing during the resume modeset if we no longer have
the same amount of bandwidth available as we had before suspend?
So far we've been getting away with this exactly by not updating
the dpcd stuff before the modeset during resume.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 8ebfb039000f6..bc138a54f8d7b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -36,6 +36,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -3320,18 +3321,21 @@ void intel_dp_sync_state(struct intel_encoder
> *encoder,
>const struct intel_crtc_state *crtc_state)
> {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -
> - if (!crtc_state)
> - return;
> + bool dpcd_updated = false;
>
> /*
>* Don't clobber DPCD if it's been already read out during output
>* setup (eDP) or detect.
>*/
> - if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> + if (crtc_state && intel_dp->dpcd[DP_DPCD_REV] == 0) {
> intel_dp_get_dpcd(intel_dp);
> + dpcd_updated = true;
> + }
>
> - intel_dp_reset_max_link_params(intel_dp);
> + intel_dp_tunnel_resume(intel_dp, dpcd_updated);
> +
> + if (crtc_state)
> + intel_dp_reset_max_link_params(intel_dp);
> }
>
> bool intel_dp_initial_fastset_check(struct intel_encoder *encoder,
> @@ -5973,6 +5977,8 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
>
> intel_pps_vdd_off_sync(intel_dp);
> +
> + intel_dp_tunnel_suspend(intel_dp);
> }
>
> void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
> --
> 2.39.2
--
Ville Syrjälä
Intel
