From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>, linux-kernel@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ssd130x: Replace simple display helpers with the atomic helpers
Date: Mon, 5 Sep 2022 13:55:01 +0200 [thread overview]
Message-ID: <49b62a63-a1d7-ca3f-abfc-df08edb46da3@redhat.com> (raw)
In-Reply-To: <bd987b93-ebcc-8fad-ee5e-2e25f4d64eaf@suse.de>
On 9/5/22 13:34, Thomas Zimmermann wrote:
[...]
>>>
>>
>> Yes, I was abusing the concept of encoder here just to have a place where
>> I could hook the enable / disable logic, since I was looking at the other
>> DRM objects helper operations structures and found that these were only
>> defined for the encoder.
>
> I liked the idea of handling backlighting here. Power on/off also seems
> sensible.
>
Ok. I'll keep that then.
>>
>> But there is technically no encoder on this device. As you can see, I was
>> using DRM_MODE_ENCODER_NONE when the encoder is initialized.
>>
>> But I notice now that the struct drm_crtc_helper_funcs also have .enable
>> and .disable callbacks, it seems I was just blind and didn't see before.
>
> You certainly want to use atomic_enable/atomic_disable. They are
> mutually exclusive with the other enable/disable functions.
>
Ah, then I wasn't blind after all. It was because the encoder was the
only DRM object that had .atomic_{en,dis}able. The CRTC only had some
.{en,disable} helper callbacks.
>>
>> Would having the init and poweroff logic in the CRTC helpers be correct
>> to you or was do you have in mind ?
>
> There's quite a bit happening in the init function. Does it have to be
> re-initialized on each enable operation? If it survives the power-off
> call, the initial init can be done in the CRTC reset function. It's
> purpose is to set hardware and software to a clean state.
>
I need to check if it survives a disable/enable cycle. Specially since
on disable the VCC regulator is disabled, which might lead to the chip
state to get lost.
> Best regards
> Thomas
>
>>
>>> Best regards
>>> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
prev parent reply other threads:[~2022-09-05 11:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-28 15:11 Javier Martinez Canillas
2022-09-05 10:41 ` Thomas Zimmermann
2022-09-05 11:00 ` Javier Martinez Canillas
2022-09-05 11:23 ` Javier Martinez Canillas
2022-09-05 11:34 ` Thomas Zimmermann
2022-09-05 11:55 ` Javier Martinez Canillas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49b62a63-a1d7-ca3f-abfc-df08edb46da3@redhat.com \
--to=javierm@redhat.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®