On Thu, Dec 3, 2020 at 10:31 PM Alex Deucher <alexdeuc...@gmail.com> wrote:
>
> On Tue, Sep 29, 2020 at 4:04 PM Alex Deucher <alexdeuc...@gmail.com> wrote:
> >
> > On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka <jan.kis...@web.de> wrote:
> > >
> > > On 10.09.20 20:18, Deucher, Alexander wrote:
> > > > [AMD Public Use]
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> On Behalf Of
> > > >> Daniel Vetter
> > > >> Sent: Monday, September 7, 2020 3:15 AM
> > > >> To: Jan Kiszka <jan.kis...@web.de>; amd-gfx list <amd-
> > > >> g...@lists.freedesktop.org>; Wentland, Harry <harry.wentl...@amd.com>;
> > > >> Kazlauskas, Nicholas <nicholas.kazlaus...@amd.com>
> > > >> Cc: dri-devel <dri-devel@lists.freedesktop.org>; intel-gfx <intel-
> > > >> g...@lists.freedesktop.org>; Thomas Zimmermann
> > > >> <tzimmerm...@suse.de>; Ville Syrjala <ville.syrj...@linux.intel.com>
> > > >> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
> > > >>
> > > >> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka <jan.kis...@web.de> wrote:
> > > >>>
> > > >>> On 11.02.20 18:04, Daniel Vetter wrote:
> > > >>>> On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> > > >>>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > >>>>>
> > > >>>>> WARN if the encoder possible_crtcs is effectively empty or contains
> > > >>>>> bits for non-existing crtcs.
> > > >>>>>
> > > >>>>> v2: Move to drm_mode_config_validate() (Daniel)
> > > >>>>> Make the docs say we WARN when this is wrong (Daniel)
> > > >>>>> Extract full_crtc_mask()
> > > >>>>>
> > > >>>>> Cc: Thomas Zimmermann <tzimmerm...@suse.de>
> > > >>>>> Cc: Daniel Vetter <dan...@ffwll.ch>
> > > >>>>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > >>>>
> > > >>>> When pushing the fixup needs to be applied before the validation
> > > >>>> patch here, because we don't want to anger the bisect gods.
> > > >>>>
> > > >>>> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> > > >>>>
> > > >>>> I think with the fixup we should be good enough with the existing
> > > >>>> nonsense in drivers. Fingers crossed.
> > > >>>> -Daniel
> > > >>>>
> > > >>>>
> > > >>>>> ---
> > > >>>>> drivers/gpu/drm/drm_mode_config.c | 27
> > > >> ++++++++++++++++++++++++++-
> > > >>>>> include/drm/drm_encoder.h | 2 +-
> > > >>>>> 2 files changed, 27 insertions(+), 2 deletions(-)
> > > >>>>>
> > > >>>>> diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > >>>>> b/drivers/gpu/drm/drm_mode_config.c
> > > >>>>> index afc91447293a..4c1b350ddb95 100644
> > > >>>>> --- a/drivers/gpu/drm/drm_mode_config.c
> > > >>>>> +++ b/drivers/gpu/drm/drm_mode_config.c
> > > >>>>> @@ -581,6 +581,29 @@ static void
> > > >> validate_encoder_possible_clones(struct drm_encoder *encoder)
> > > >>>>> encoder->possible_clones, encoder_mask); }
> > > >>>>>
> > > >>>>> +static u32 full_crtc_mask(struct drm_device *dev) {
> > > >>>>> + struct drm_crtc *crtc;
> > > >>>>> + u32 crtc_mask = 0;
> > > >>>>> +
> > > >>>>> + drm_for_each_crtc(crtc, dev)
> > > >>>>> + crtc_mask |= drm_crtc_mask(crtc);
> > > >>>>> +
> > > >>>>> + return crtc_mask;
> > > >>>>> +}
> > > >>>>> +
> > > >>>>> +static void validate_encoder_possible_crtcs(struct drm_encoder
> > > >>>>> +*encoder) {
> > > >>>>> + u32 crtc_mask = full_crtc_mask(encoder->dev);
> > > >>>>> +
> > > >>>>> + WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> > > >>>>> + (encoder->possible_crtcs & ~crtc_mask) != 0,
> > > >>>>> + "Bogus possible_crtcs: "
> > > >>>>> + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc
> > > >>>>> mask=0x%x)\n",
> > > >>>>> + encoder->base.id, encoder->name,
> > > >>>>> + encoder->possible_crtcs, crtc_mask); }
> > > >>>>> +
> > > >>>>> void drm_mode_config_validate(struct drm_device *dev) {
> > > >>>>> struct drm_encoder *encoder;
> > > >>>>> @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
> > > >> drm_device *dev)
> > > >>>>> drm_for_each_encoder(encoder, dev)
> > > >>>>> fixup_encoder_possible_clones(encoder);
> > > >>>>>
> > > >>>>> - drm_for_each_encoder(encoder, dev)
> > > >>>>> + drm_for_each_encoder(encoder, dev) {
> > > >>>>> validate_encoder_possible_clones(encoder);
> > > >>>>> + validate_encoder_possible_crtcs(encoder);
> > > >>>>> + }
> > > >>>>> }
> > > >>>>> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> > > >>>>> index 3741963b9587..b236269f41ac 100644
> > > >>>>> --- a/include/drm/drm_encoder.h
> > > >>>>> +++ b/include/drm/drm_encoder.h
> > > >>>>> @@ -142,7 +142,7 @@ struct drm_encoder {
> > > >>>>> * the bits for all &drm_crtc objects this encoder can be
> > > >>>>> connected to
> > > >>>>> * before calling drm_dev_register().
> > > >>>>> *
> > > >>>>> - * In reality almost every driver gets this wrong.
> > > >>>>> + * You will get a WARN if you get this wrong in the driver.
> > > >>>>> *
> > > >>>>> * Note that since CRTC objects can't be hotplugged the
> > > >>>>> assigned
> > > >> indices
> > > >>>>> * are stable and hence known before registering all objects.
> > > >>>>> --
> > > >>>>> 2.24.1
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>> Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
> > > >>
> > > >> Adding amdgpu display folks.
> > > >
> > > > I took a quick look at this and it looks like we limit the number of
> > > > crtcs later in the mode init process if the number of physical displays
> > > > can't actually use more crtcs. E.g., the physical board configuration
> > > > would only allow for 3 active displays even if the hardware technically
> > > > supports 4 crtcs. I presume that way we can just leave the additional
> > > > hardware power gated all the time.
> > > >
> > >
> > > So, will this be fixed any time soon? I don't feel qualified writing
> > > such a patch but I would obviously be happy to test one.
> >
> > It's harmless, but I'll send out a patch soon.
>
> I believe the attached patch should fix this.
fwiw rb: me
Probably want to add the right Fixes: line too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
