Subject: Re: [PATCH v1 5/5] coresight: etm4x: save/restore state across CPU low power states

From: Sudeep Holla <[email-masked]>
Date: Thu, 20 Jun 2019 17:34:26 +0100

On Thu, Jun 20, 2019 at 10:14:04AM -0600, Mathieu Poirier wrote:
> On Thu, 20 Jun 2019 at 09:41, Sudeep Holla <[email-masked]> wrote:
> >

[...]

> > Sorry but even then I prefer it not to be default and force extra work
> > to the people who add support and constantly be reminded that it's
> > broken and they are deviating from default behaviour in the kernel
> > which may come and latency penalty.
> >
> > Making it default may hide the problem if Linux is used for some validation.
> >
> > Also we hardly have 3-4 platforms in upstream that support coresight,
> > and many are broken except Juno. But that doesn't imply all others
> > are broken and we just can't derive that unless we have more information.
>
> For now we have a clear trend.  To me it is not a matter of broken vs.
> non-broken but more about what people want to do or can
> (realistically) do.
>

No disagreement there.

> The coresight specification is broad and very permissive in terms of
> implementation defined choices.  It is not because the TRCPDCR.PU it
> not taken into account by a platform that it is automatically broken.
> This could be a design choice or a trade off.  We already have two
> ways of putting a CPU to sleep (architected or OS driven), we simply
> do the same here for coresight.
>

Sure, if the term "broken" is inappropriate I am fine if anything else
is used. The point is we are adding an idle notifier that adds latency
and must be done if and only if necessary.

How you identify that and implement doesn't bother me much, making
that default just based on the fact that more platforms need it
compared to others definitely does. So I am fine if this needs to be
advertised *not broken* but *by design*, sure go for it.

My main concern was additional latency that this introduces for platforms
that don't require.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel