drm/ssd130x: Init display before the SSD130X_DISPLAY_ON command
authorJavier Martinez Canillas <javierm@redhat.com>
Wed, 25 Jan 2023 18:42:30 +0000 (19:42 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 9 Feb 2023 10:28:02 +0000 (11:28 +0100)
commit9e0097cb51e69f4b7d1c3823fbacc3725f48ce4e
tree1b20ad4ede6b20981004a7d66c4a325e14ee0663
parentc590a4a59a985f8f12d358340825e936890f5804
drm/ssd130x: Init display before the SSD130X_DISPLAY_ON command

[ Upstream commit 343c700480982214dc4f834f536a49a4098e556a ]

Commit 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the
atomic helpers") changed the driver to just use the atomic helpers instead
of the simple KMS abstraction layer.

But the commit also made a subtle change on the display power sequence and
initialization order, by moving the ssd130x_power_on() call to the encoder
.atomic_enable handler and the ssd130x_init() call to CRTC .reset handler.

Before this change, both ssd130x_power_on() and ssd130x_init() were called
in the simple display pipeline .enable handler, so the display was already
initialized by the time the SSD130X_DISPLAY_ON command was sent.

For some reasons, it only made the ssd130x SPI driver to fail but the I2C
was still working. That is the reason why the bug was not noticed before.

To revert to the old driver behavior, move the ssd130x_init() call to the
encoder .atomic_enable as well. Besides fixing the panel not being turned
on when using SPI, it also gets rid of the custom CRTC .reset callback.

Fixes: 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the atomic helpers")
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230125184230.3343206-1-javierm@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/gpu/drm/solomon/ssd130x.c