| Message ID | 20200430091330.9824-1-tzimmermann@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/ast: Don't check new mode if CRTC is being disabled | expand |
Hi Thomas. On Thu, Apr 30, 2020 at 11:13:30AM +0200, Thomas Zimmermann wrote: > Suspending failed because there's no mode if the CRTC is being > disabled. Early-out in this case. This fixes runtime PM for ast. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Don't you miss: Reported-by: Tested-by: Fixes: ??? Sam > --- > drivers/gpu/drm/ast/ast_mode.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > index 7a9f20a2fd303..089b7d9a0cf3f 100644 > --- a/drivers/gpu/drm/ast/ast_mode.c > +++ b/drivers/gpu/drm/ast/ast_mode.c > @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, > return -EINVAL; > } > > + if (!state->enable) > + return 0; /* no checks required if CRTC is being disabled */ > + > ast_state = to_ast_crtc_state(state); > > format = ast_state->format; > -- > 2.26.0
Hi Am 30.04.20 um 11:22 schrieb Sam Ravnborg: > Hi Thomas. > > On Thu, Apr 30, 2020 at 11:13:30AM +0200, Thomas Zimmermann wrote: >> Suspending failed because there's no mode if the CRTC is being >> disabled. Early-out in this case. This fixes runtime PM for ast. >> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > > Don't you miss: > > Reported-by: > Tested-by: Waiting for the reporter's ok. > Fixes: Indeed. :( Best regards Thomas > ??? > > Sam > >> --- >> drivers/gpu/drm/ast/ast_mode.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c >> index 7a9f20a2fd303..089b7d9a0cf3f 100644 >> --- a/drivers/gpu/drm/ast/ast_mode.c >> +++ b/drivers/gpu/drm/ast/ast_mode.c >> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, >> return -EINVAL; >> } >> >> + if (!state->enable) >> + return 0; /* no checks required if CRTC is being disabled */ >> + >> ast_state = to_ast_crtc_state(state); >> >> format = ast_state->format; >> -- >> 2.26.0 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
Hi Thomas, Couple of fly-by ideas/suggestions. On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Suspending failed because there's no mode if the CRTC is being > disabled. Early-out in this case. This fixes runtime PM for ast. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- > drivers/gpu/drm/ast/ast_mode.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > index 7a9f20a2fd303..089b7d9a0cf3f 100644 > --- a/drivers/gpu/drm/ast/ast_mode.c > +++ b/drivers/gpu/drm/ast/ast_mode.c > @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, > return -EINVAL; Unrelated: This feels quite dirty. If AST1180 does not support atomic modeset simply remove the DRIVER_ATOMIC bit. You can do that at runtime, via drm_device::driver_features in say, ast_detect_chip()? The drm_driver::driver_features is immutable, or it ought to be. > } > > + if (!state->enable) > + return 0; /* no checks required if CRTC is being disabled */ > + I cannot think of a reason why a driver would need to perform crtc_atomic_check, if the crtc is being disabled. Can you spot any? If not, this should be better served in core, which calls this callback. Correct? HTH -Emil
Hi Emil Am 01.05.20 um 15:20 schrieb Emil Velikov: > Hi Thomas, > > Couple of fly-by ideas/suggestions. > > On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> >> Suspending failed because there's no mode if the CRTC is being >> disabled. Early-out in this case. This fixes runtime PM for ast. >> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >> --- >> drivers/gpu/drm/ast/ast_mode.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c >> index 7a9f20a2fd303..089b7d9a0cf3f 100644 >> --- a/drivers/gpu/drm/ast/ast_mode.c >> +++ b/drivers/gpu/drm/ast/ast_mode.c >> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, >> return -EINVAL; > Unrelated: > This feels quite dirty. If AST1180 does not support atomic modeset > simply remove the DRIVER_ATOMIC bit. > You can do that at runtime, via drm_device::driver_features in say, > ast_detect_chip()? The line you commented on dates back to non-atomic modesetting, but I don't know what the story behind AST1180 is. It is explicitly disabled in the list of PCI IDs, but the driver has plenty of code for it. It looks as if the chip can only do pageflipping with a pre-set video mode. As it is right now, the AST1180 code could probably be deleted entirely. > > The drm_driver::driver_features is immutable, or it ought to be. > >> } >> >> + if (!state->enable) >> + return 0; /* no checks required if CRTC is being disabled */ >> + > I cannot think of a reason why a driver would need to perform > crtc_atomic_check, if the crtc is being disabled. > Can you spot any? If not, this should be better served in core, which > calls this callback. > Correct? Ast is a bit of a special case, because it tests the incoming mode against a list of re-defined modes. With the crtc being disabled, the incoming mode is 0 in all fields. Obviously that's not a valid mode, and we need that additional test here. In the general case, I'd see 'crtc check' as part of the larger atomic infrastructure. I can imagine that configurations require the CRTC to be enabled before other HW blocks work. So a driver might have a reason to run crtc's check even for disabled crtcs (at least to verify that the crtc is not disabled). I don't think this can be handled in the core easily. Best regards Thomas > > HTH > -Emil > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
On Mon, May 04, 2020 at 02:07:22PM +0200, Thomas Zimmermann wrote: > Hi Emil > > Am 01.05.20 um 15:20 schrieb Emil Velikov: > > Hi Thomas, > > > > Couple of fly-by ideas/suggestions. > > > > On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >> > >> Suspending failed because there's no mode if the CRTC is being > >> disabled. Early-out in this case. This fixes runtime PM for ast. > >> > >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > >> --- > >> drivers/gpu/drm/ast/ast_mode.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > >> index 7a9f20a2fd303..089b7d9a0cf3f 100644 > >> --- a/drivers/gpu/drm/ast/ast_mode.c > >> +++ b/drivers/gpu/drm/ast/ast_mode.c > >> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, > >> return -EINVAL; > > Unrelated: > > This feels quite dirty. If AST1180 does not support atomic modeset > > simply remove the DRIVER_ATOMIC bit. > > You can do that at runtime, via drm_device::driver_features in say, > > ast_detect_chip()? > > The line you commented on dates back to non-atomic modesetting, but I > don't know what the story behind AST1180 is. It is explicitly disabled > in the list of PCI IDs, but the driver has plenty of code for it. It > looks as if the chip can only do pageflipping with a pre-set video mode. > > As it is right now, the AST1180 code could probably be deleted entirely. > > > > > The drm_driver::driver_features is immutable, or it ought to be. > > > >> } > >> > >> + if (!state->enable) > >> + return 0; /* no checks required if CRTC is being disabled */ > >> + > > I cannot think of a reason why a driver would need to perform > > crtc_atomic_check, if the crtc is being disabled. > > Can you spot any? If not, this should be better served in core, which > > calls this callback. > > Correct? > Ast is a bit of a special case, because it tests the incoming mode > against a list of re-defined modes. With the crtc being disabled, the > incoming mode is 0 in all fields. Obviously that's not a valid mode, and > we need that additional test here. > > In the general case, I'd see 'crtc check' as part of the larger atomic > infrastructure. I can imagine that configurations require the CRTC to be > enabled before other HW blocks work. So a driver might have a reason to > run crtc's check even for disabled crtcs (at least to verify that the > crtc is not disabled). I don't think this can be handled in the core easily. Jumping out of ->atomic_check callbacks when stuff is all off is fairly standard pattern. So much standard that I'm kinda wondering whether we shouldn't just make it the default in atomic helpers - so many drivers forget to do it and break in funny ways. -Daniel > > Best regards > Thomas > > > > > HTH > > -Emil > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, 4 May 2020 at 13:07, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi Emil > > Am 01.05.20 um 15:20 schrieb Emil Velikov: > > Hi Thomas, > > > > Couple of fly-by ideas/suggestions. > > > > On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >> > >> Suspending failed because there's no mode if the CRTC is being > >> disabled. Early-out in this case. This fixes runtime PM for ast. > >> > >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > >> --- > >> drivers/gpu/drm/ast/ast_mode.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > >> index 7a9f20a2fd303..089b7d9a0cf3f 100644 > >> --- a/drivers/gpu/drm/ast/ast_mode.c > >> +++ b/drivers/gpu/drm/ast/ast_mode.c > >> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, > >> return -EINVAL; > > Unrelated: > > This feels quite dirty. If AST1180 does not support atomic modeset > > simply remove the DRIVER_ATOMIC bit. > > You can do that at runtime, via drm_device::driver_features in say, > > ast_detect_chip()? > > The line you commented on dates back to non-atomic modesetting, but I > don't know what the story behind AST1180 is. It is explicitly disabled > in the list of PCI IDs, but the driver has plenty of code for it. It > looks as if the chip can only do pageflipping with a pre-set video mode. > > As it is right now, the AST1180 code could probably be deleted entirely. > No modeset support at all? Ouch. Removing is one option a shorter/simpler one will be to expose zero connectors. So any crazy^W brave soul can reinstate AST1180 support. In either way - it's something for another day/series. > > > > The drm_driver::driver_features is immutable, or it ought to be. > > > >> } > >> > >> + if (!state->enable) > >> + return 0; /* no checks required if CRTC is being disabled */ > >> + > > I cannot think of a reason why a driver would need to perform > > crtc_atomic_check, if the crtc is being disabled. > > Can you spot any? If not, this should be better served in core, which > > calls this callback. > > Correct? > Ast is a bit of a special case, because it tests the incoming mode > against a list of re-defined modes. With the crtc being disabled, the > incoming mode is 0 in all fields. Obviously that's not a valid mode, and > we need that additional test here. > > In the general case, I'd see 'crtc check' as part of the larger atomic > infrastructure. I can imagine that configurations require the CRTC to be > enabled before other HW blocks work. So a driver might have a reason to > run crtc's check even for disabled crtcs (at least to verify that the > crtc is not disabled). I don't think this can be handled in the core easily. > Ack, makes sense. Thanks Emil
Hi Am 04.05.20 um 17:31 schrieb Daniel Vetter: > On Mon, May 04, 2020 at 02:07:22PM +0200, Thomas Zimmermann wrote: >> Hi Emil >> >> Am 01.05.20 um 15:20 schrieb Emil Velikov: >>> Hi Thomas, >>> >>> Couple of fly-by ideas/suggestions. >>> >>> On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>> >>>> Suspending failed because there's no mode if the CRTC is being >>>> disabled. Early-out in this case. This fixes runtime PM for ast. >>>> >>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >>>> --- >>>> drivers/gpu/drm/ast/ast_mode.c | 3 +++ >>>> 1 file changed, 3 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c >>>> index 7a9f20a2fd303..089b7d9a0cf3f 100644 >>>> --- a/drivers/gpu/drm/ast/ast_mode.c >>>> +++ b/drivers/gpu/drm/ast/ast_mode.c >>>> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, >>>> return -EINVAL; >>> Unrelated: >>> This feels quite dirty. If AST1180 does not support atomic modeset >>> simply remove the DRIVER_ATOMIC bit. >>> You can do that at runtime, via drm_device::driver_features in say, >>> ast_detect_chip()? >> >> The line you commented on dates back to non-atomic modesetting, but I >> don't know what the story behind AST1180 is. It is explicitly disabled >> in the list of PCI IDs, but the driver has plenty of code for it. It >> looks as if the chip can only do pageflipping with a pre-set video mode. >> >> As it is right now, the AST1180 code could probably be deleted entirely. >> >>> >>> The drm_driver::driver_features is immutable, or it ought to be. >>> >>>> } >>>> >>>> + if (!state->enable) >>>> + return 0; /* no checks required if CRTC is being disabled */ >>>> + >>> I cannot think of a reason why a driver would need to perform >>> crtc_atomic_check, if the crtc is being disabled. >>> Can you spot any? If not, this should be better served in core, which >>> calls this callback. >>> Correct? >> Ast is a bit of a special case, because it tests the incoming mode >> against a list of re-defined modes. With the crtc being disabled, the >> incoming mode is 0 in all fields. Obviously that's not a valid mode, and >> we need that additional test here. >> >> In the general case, I'd see 'crtc check' as part of the larger atomic >> infrastructure. I can imagine that configurations require the CRTC to be >> enabled before other HW blocks work. So a driver might have a reason to >> run crtc's check even for disabled crtcs (at least to verify that the >> crtc is not disabled). I don't think this can be handled in the core easily. > > Jumping out of ->atomic_check callbacks when stuff is all off is fairly > standard pattern. So much standard that I'm kinda wondering whether we > shouldn't just make it the default in atomic helpers - so many drivers > forget to do it and break in funny ways. If there comes a driver that really must handle the 'disable case' in its check handler, such a change would be hard to revert. Removing the check from the DRM core could regress drivers that depend on the new semantics. Best regards Thomas > -Daniel > >> >> Best regards >> Thomas >> >>> >>> HTH >>> -Emil >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >> >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 Nürnberg, Germany >> (HRB 36809, AG Nürnberg) >> Geschäftsführer: Felix Imendörffer >> > > > > >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >
On Wed, May 06, 2020 at 10:06:15AM +0200, Thomas Zimmermann wrote: > Hi > > Am 04.05.20 um 17:31 schrieb Daniel Vetter: > > On Mon, May 04, 2020 at 02:07:22PM +0200, Thomas Zimmermann wrote: > >> Hi Emil > >> > >> Am 01.05.20 um 15:20 schrieb Emil Velikov: > >>> Hi Thomas, > >>> > >>> Couple of fly-by ideas/suggestions. > >>> > >>> On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>> > >>>> Suspending failed because there's no mode if the CRTC is being > >>>> disabled. Early-out in this case. This fixes runtime PM for ast. > >>>> > >>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > >>>> --- > >>>> drivers/gpu/drm/ast/ast_mode.c | 3 +++ > >>>> 1 file changed, 3 insertions(+) > >>>> > >>>> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > >>>> index 7a9f20a2fd303..089b7d9a0cf3f 100644 > >>>> --- a/drivers/gpu/drm/ast/ast_mode.c > >>>> +++ b/drivers/gpu/drm/ast/ast_mode.c > >>>> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, > >>>> return -EINVAL; > >>> Unrelated: > >>> This feels quite dirty. If AST1180 does not support atomic modeset > >>> simply remove the DRIVER_ATOMIC bit. > >>> You can do that at runtime, via drm_device::driver_features in say, > >>> ast_detect_chip()? > >> > >> The line you commented on dates back to non-atomic modesetting, but I > >> don't know what the story behind AST1180 is. It is explicitly disabled > >> in the list of PCI IDs, but the driver has plenty of code for it. It > >> looks as if the chip can only do pageflipping with a pre-set video mode. > >> > >> As it is right now, the AST1180 code could probably be deleted entirely. > >> > >>> > >>> The drm_driver::driver_features is immutable, or it ought to be. > >>> > >>>> } > >>>> > >>>> + if (!state->enable) > >>>> + return 0; /* no checks required if CRTC is being disabled */ > >>>> + > >>> I cannot think of a reason why a driver would need to perform > >>> crtc_atomic_check, if the crtc is being disabled. > >>> Can you spot any? If not, this should be better served in core, which > >>> calls this callback. > >>> Correct? > >> Ast is a bit of a special case, because it tests the incoming mode > >> against a list of re-defined modes. With the crtc being disabled, the > >> incoming mode is 0 in all fields. Obviously that's not a valid mode, and > >> we need that additional test here. > >> > >> In the general case, I'd see 'crtc check' as part of the larger atomic > >> infrastructure. I can imagine that configurations require the CRTC to be > >> enabled before other HW blocks work. So a driver might have a reason to > >> run crtc's check even for disabled crtcs (at least to verify that the > >> crtc is not disabled). I don't think this can be handled in the core easily. > > > > Jumping out of ->atomic_check callbacks when stuff is all off is fairly > > standard pattern. So much standard that I'm kinda wondering whether we > > shouldn't just make it the default in atomic helpers - so many drivers > > forget to do it and break in funny ways. > > If there comes a driver that really must handle the 'disable case' in > its check handler, such a change would be hard to revert. Removing the > check from the DRM core could regress drivers that depend on the new > semantics. Yeah I know, that's why I don't want to push this into helpers (it wouldn't ever be in core code). But it surely is tempting, because we have tons of bugs in this area. I've made a patch series a while ago that only cleaned up some of the minor confusion between plane_state->crtc and plane_state->fb (they're only set together or neither). Losing choice either way :-/ -Daniel > > Best regards > Thomas > > > -Daniel > > > >> > >> Best regards > >> Thomas > >> > >>> > >>> HTH > >>> -Emil > >>> _______________________________________________ > >>> dri-devel mailing list > >>> dri-devel@lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >>> > >> > >> -- > >> Thomas Zimmermann > >> Graphics Driver Developer > >> SUSE Software Solutions Germany GmbH > >> Maxfeldstr. 5, 90409 Nürnberg, Germany > >> (HRB 36809, AG Nürnberg) > >> Geschäftsführer: Felix Imendörffer > >> > > > > > > > > > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer >
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 7a9f20a2fd303..089b7d9a0cf3f 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, return -EINVAL; } + if (!state->enable) + return 0; /* no checks required if CRTC is being disabled */ + ast_state = to_ast_crtc_state(state); format = ast_state->format;
Suspending failed because there's no mode if the CRTC is being disabled. Early-out in this case. This fixes runtime PM for ast. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> --- drivers/gpu/drm/ast/ast_mode.c | 3 +++ 1 file changed, 3 insertions(+)