From: Petr Mladek <pmladek@suse.com>
To: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
John Ogness <john.ogness@linutronix.de>,
Javier Martinez Canillas <javierm@redhat.com>,
"Guilherme G . Piccoli" <gpiccoli@igalia.com>,
bluescreen_avenger@verizon.net,
Caleb Connolly <caleb.connolly@linaro.org>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 5/6] drm/log: Implement suspend/resume
Date: Thu, 24 Oct 2024 16:34:03 +0200 [thread overview]
Message-ID: <Zxpa2zt1P9Avy4Pm@pathway.suse.cz> (raw)
In-Reply-To: <20241023121145.1321921-6-jfalempe@redhat.com>
On Wed 2024-10-23 14:00:13, Jocelyn Falempe wrote:
> The console is already suspended in printk.c.
Does this mean that drm_log_client_suspend() is called
after suspend_console(), please?
By other words, does it mean that "dlog->suspended == true" is set
only when CON_SUSPENDED is already set in the related con->flags?
> Just make sure we don't write to the framebuffer while the graphic
> driver is suspended.
> It may lose a few messages between graphic suspend and console
> suspend.
The messages should not get lost when the console is properly
suspended by suspend_console(), set CON_SUSPENDED.
Or maybe, I do not understand it correctly. Maybe you want to say
that it should work correctly even without this patch. And this
patch creates just a safeguard to make sure that nothing wrong
happens even when suspend_console() was not called from some
reasons.
Note: I tried to check the order by reading the code. But
drm_log_client_suspend() was called via too many layers.
And I was not able to find where exactly it was called,
for example, from hibernate() in kernel/power/hibernate.c
> --- a/drivers/gpu/drm/drm_log.c
> +++ b/drivers/gpu/drm/drm_log.c
> @@ -310,10 +311,32 @@ static int drm_log_client_hotplug(struct drm_client_dev *client)
> return 0;
> }
>
> +static int drm_log_client_suspend(struct drm_client_dev *client, bool _console_lock)
> +{
> + struct drm_log *dlog = client_to_drm_log(client);
> +
> + mutex_lock(&dlog->lock);
> + dlog->suspended = true;
> + mutex_unlock(&dlog->lock);
It might also be possible to explicitly set the CON_SUSPENDED flag
here to be always on the safe side. We could create variant of
suspend_console() just for one console. Something like:
void suspend_one_console(struct console *con)
{
struct console *con;
if (!console_suspend_enabled)
return;
pr_info("Suspending console(%s) (use no_console_suspend to debug)\n");
pr_flush(1000, true);
console_list_lock();
if (con && console_is_registered_locked(con))
console_srcu_write_flags(con, con->flags | CON_SUSPENDED);
console_list_unlock();
/*
* Ensure that all SRCU list walks have completed. All printing
* contexts must be able to see that they are suspended so that it
* is guaranteed that all printing has stopped when this function
* completes.
*/
synchronize_srcu(&console_srcu);
}
and call here:
suspend_one_console(dlog->con);
But this is not needed when the console is already supposed to be
disabled here. If this is the case then it might be better
to just check and warn when it does not happen. Something like:
void assert_console_suspended(struct console *con)
{
int cookie;
cookie = console_srcu_read_lock();
/* Do not care about unregistered console */
if (!con || hlist_unhashed_lockless(&con->node))
goto out;
if (WARN_ON_ONCE(!(console_srcu_read_flags(con) & CON_SUSPENDED)))
pr_flush(1000, true);
out:
console_srcu_read_unlock(cookie);
}
> + return 0;
> +}
Best Regards,
Petr
PS: I have vacation the following week and might not be able to
follow the discussion before I am back.
next prev parent reply other threads:[~2024-10-24 14:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 12:00 [PATCH v5 0/6] drm/log: Introduce a new boot logger to draw the kmsg on the screen Jocelyn Falempe
2024-10-23 12:00 ` [PATCH v5 1/6] drm/panic: Move drawing functions to drm_draw Jocelyn Falempe
2024-10-23 12:00 ` [PATCH v5 2/6] drm/log: Introduce a new boot logger to draw the kmsg on the screen Jocelyn Falempe
2024-10-23 12:00 ` [PATCH v5 3/6] drm/log: Do not draw if drm_master is taken Jocelyn Falempe
2024-10-23 12:00 ` [PATCH v5 4/6] drm/log: Color the timestamp, to improve readability Jocelyn Falempe
2024-10-23 12:00 ` [PATCH v5 5/6] drm/log: Implement suspend/resume Jocelyn Falempe
2024-10-24 14:34 ` Petr Mladek [this message]
2024-10-24 23:11 ` Jocelyn Falempe
2024-10-25 9:46 ` Jocelyn Falempe
2024-11-01 16:00 ` Petr Mladek
2024-11-04 9:56 ` Jocelyn Falempe
2024-11-04 10:46 ` John Ogness
2024-11-04 14:15 ` Petr Mladek
2024-11-04 14:36 ` Jocelyn Falempe
2024-11-04 15:32 ` John Ogness
2024-11-05 12:19 ` Petr Mladek
2024-11-05 14:19 ` John Ogness
2024-10-23 12:00 ` [PATCH v5 6/6] drm/log: Add integer scaling support Jocelyn Falempe
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=Zxpa2zt1P9Avy4Pm@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=airlied@gmail.com \
--cc=bluescreen_avenger@verizon.net \
--cc=caleb.connolly@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gpiccoli@igalia.com \
--cc=javierm@redhat.com \
--cc=jfalempe@redhat.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.