All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: Andreas Kemnade <andreas@kemnade.info>,
	mturquette@baylibre.com, sboyd@kernel.org,
	linux-omap@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, paul@pwsan.com,
	letux-kernel@openphoenux.org, Suman Anna <s-anna@ti.com>
Subject: Re: [PATCH RFC 0/2] mach-omap2: handle autoidle denial
Date: Thu, 4 Oct 2018 08:07:51 -0700	[thread overview]
Message-ID: <20181004150751.GF5662@atomide.com> (raw)
In-Reply-To: <013b01a1-2593-bdc0-dd9a-e5a114388067@ti.com>

* Tero Kristo <t-kristo@ti.com> [181004 14:47]:
> On 04/10/18 17:25, Tony Lindgren wrote:
> > It seems we should just provide a generic interface for
> > clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll
> > be forever stuck with pdata callbacks it seems.
> 
> The TI clock driver is actually providing these APIs, so that should be
> fine. I don't think there is any use / need for pdata callbacks atm, it just
> happens hwmod core is calling these at the moment which might have confused
> you.

Hmm OK. So do we already have some way to deny autoidle for a
clock from ti-sysc.c driver without pdata callbacks?

Suman pointed out few days ago that for a reset driver to work
we must do clkdm_deny_idle() and clkdm_allow_idle() as the hwmod
code does. I gues that really just boils down to doing clk deny
idle and allow idle on the clockdomain clkctrl clock?

Regards,

Tony

  reply	other threads:[~2018-10-04 15:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-04  5:51 [PATCH RFC 0/2] mach-omap2: handle autoidle denial Andreas Kemnade
2018-10-04  5:51 ` [PATCH RFC 1/2] clk: ti: add a usecount for autoidle Andreas Kemnade
2018-10-04 14:40   ` Tero Kristo
2018-10-04 14:40     ` Tero Kristo
2018-10-04 19:34     ` Andreas Kemnade
2018-10-04 19:34       ` Andreas Kemnade
2018-10-04  5:51 ` [PATCH RFC 2/2] arm: mach-omap2: setup iclk autoidle according to flags Andreas Kemnade
2018-10-04 14:25 ` [PATCH RFC 0/2] mach-omap2: handle autoidle denial Tony Lindgren
2018-10-04 14:42   ` Tero Kristo
2018-10-04 14:42     ` Tero Kristo
2018-10-04 15:07     ` Tony Lindgren [this message]
2018-10-04 15:48       ` Tero Kristo
2018-10-04 15:48         ` Tero Kristo
2018-10-04 16:08         ` Tony Lindgren

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=20181004150751.GF5662@atomide.com \
    --to=tony@atomide.com \
    --cc=andreas@kemnade.info \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=paul@pwsan.com \
    --cc=s-anna@ti.com \
    --cc=sboyd@kernel.org \
    --cc=t-kristo@ti.com \
    /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.