linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Sebastian Reichel <sre@kernel.org>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Aaro Koskinen" <aaro.koskinen@iki.fi>,
	"Pavel Machek" <pavel@ucw.cz>,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Pali Rohár" <pali.rohar@gmail.com>
Subject: Re: [PATCH 5/6] HSI: omap_ssi: built omap_ssi and omap_ssi_port into one module
Date: Tue, 3 May 2016 10:32:39 -0700	[thread overview]
Message-ID: <20160503173239.GO5995@atomide.com> (raw)
In-Reply-To: <1461982153-19139-6-git-send-email-sre@kernel.org>

* Sebastian Reichel <sre@kernel.org> [160429 19:11]:
> Merge omap_ssi and omap_ssi_port into one module. This
> fixes problems with module cycle dependencies introduced
> by future patches.

Can you please check against the hardware for the split?
For reference, below is what I dumped out from dm3730 for
the modules on the L4 interconnect:

0x48000000 + 0x40000 + 0x18000 = 0x48058000, size 0x1000, parent with sysc
 0x48000000 + 0x40000 + 0x19000 = 0x48059000, size 0x1000, gdd
 0x48000000 + 0x40000 + 0x1a000 = 0x4805a000, size 0x1000, ssi_port1
 0x48000000 + 0x40000 + 0x1b000 = 0x4805b000, size 0x1000, ssi_port2

0x48000000 + 0x40000 + 0x1c000 = 0x4805c000, size 0x1000, target agent

So the parent target module at 0x48058000 controls everything
with the sysc register. The gdd, ssi_port1 and ssi_port2 are
children of the parent target module at 0x48058000 and should
not have any sysc related registers.

Can you please check if gdd, ssi_port1 and ssi_port2 have any
sysc related registers too? :) If they do, then they too can
idle on their own but most likely still depend on the parent
module.

The target agent above is a separate module with the
interconnect related registers, no need to do anything with
that AFAIK.

I believe this is the same for 34xx too but have not dumped it
out of the hardware. I can do that if the above does not match
what you're seeing.

If we want to have separate driver modules, you can do this:

1. Have the parent target module at 0x4805800 do PM runtime
   calls, they then propagate to the hwmod code properly for
   the ti,hwmods = "ssi" entry. This module can be minimal,
   and can also have child devices within it's first 0x1000
   sized range if needed.

2. Have the parent target module probe the child device
   drivers as needed with of_platform_populate() at the end
   of it's probe. The children can't be pm_runtime_irq_safe
   as it permanently blocks the idling of the parent.

3. Have the the parent target module at 0x4805800 implement
   PM runtime for it's children by registering
   struct dev_pm_ops for them.

If you really want to have them all as a single module then
that should work too as long as there's only one set of sysc
related registers.

Regards,

Tony

  parent reply	other threads:[~2016-05-03 17:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-30  2:09 [PATCH 0/6] omap-ssi cleanups + dvfs support Sebastian Reichel
2016-04-30  2:09 ` [PATCH 1/6] HSI: omap_ssi_port: switch to gpiod API Sebastian Reichel
2016-05-02  7:06   ` Pavel Machek
2016-04-30  2:09 ` [PATCH 2/6] HSI: omap_ssi: fix module unloading Sebastian Reichel
2016-05-02  7:06   ` Pavel Machek
2016-04-30  2:09 ` [PATCH 3/6] HSI: omap_ssi: make sure probe stays available Sebastian Reichel
2016-04-30  2:09 ` [PATCH 4/6] HSI: omap_ssi: fix removal of port platform device Sebastian Reichel
2016-05-01  9:41   ` Pavel Machek
2016-04-30  2:09 ` [PATCH 5/6] HSI: omap_ssi: built omap_ssi and omap_ssi_port into one module Sebastian Reichel
2016-05-01  9:43   ` Pavel Machek
2016-05-01 19:34     ` Sebastian Reichel
2016-05-01 21:22       ` Pavel Machek
2016-05-03 17:32   ` Tony Lindgren [this message]
2016-05-09 20:43     ` Sebastian Reichel
2016-05-09 21:35       ` Tony Lindgren
2016-04-30  2:09 ` [PATCH 6/6] HSI: omap-ssi: add clk change support Sebastian Reichel
2016-05-01 10:03   ` Pavel Machek

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=20160503173239.GO5995@atomide.com \
    --to=tony@atomide.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=sre@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).