From: Tony Lindgren <tony@atomide.com>
To: Suman Anna <s-anna@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
Bjorn Helgaas <bhelgaas@google.com>,
richardcochran@gmail.com, Russell King <linux@arm.linux.org.uk>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, nsekhar@ti.com,
Paul Walmsley <paul@pwsan.com>
Subject: Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
Date: Thu, 28 Jan 2016 10:31:56 -0800 [thread overview]
Message-ID: <20160128183156.GH19432@atomide.com> (raw)
In-Reply-To: <56A94FB7.6020903@ti.com>
* Suman Anna <s-anna@ti.com> [160127 15:17]:
> On 01/27/2016 12:56 PM, Tony Lindgren wrote:
> > * Suman Anna <s-anna@ti.com> [160127 10:17]:
> >> On 01/27/2016 11:31 AM, Tony Lindgren wrote:
> >>> Why do you need another reset here? Can't you just implement PM runtime
> >>> in the driver and do the usual pm_runtime_put_sync followed by
> >>> pm_runtime_disable?
> >>
> >> The omap_hwmod_enable/disable code does not deal with hardresets (PRCM
> >> reset lines) and so the pm_runtime_get_sync/put_sync only end up dealing
> >> with clocks, and we need to invoke the reset functions separately.
> >> Modules with softresets in SYSCONFIG are ok, as they are dealt with
> >> properly.
> >
> > Hmm _reset() in omap_hwmod.c has this to call _assert_hardreset:
> >
> > if (oh->class->reset) {
> > r = oh->class->reset(oh);
> > } else {
> > if (oh->rst_lines_cnt > 0) {
> > for (i = 0; i < oh->rst_lines_cnt; i++)
> > _assert_hardreset(oh, oh->rst_lines[i].name);
> > return 0;
> > } else {
> > r = _ocp_softreset(oh);
> > if (r == -ENOENT)
> > r = 0;
> > }
> > }
>
> Right, hwmod code does the initial reset.
>
> > Care to explain what exactly the problem with the hwmod code not doing
> > the reset on init?
>
> And we only need to deassert the reset in probe. Technically, we don't
> need to assert first and deassert in probe, and that was a design choice
> made by Kishon.
OK so if hwmod code has already done the reset, then why would you need
to deassert reset in the device driver probe?
> > And why do you need to do another reset in dra7xx_pcie_remove()?
>
> Primarily to restore the reset state back to what it was after the
> driver remove gets called. We cannot call deassert twice without calling
> a assert in between. Kishon had originally added the assert and deassert
> only in probe, but nothing in remove, they ought to be deassert in probe
> and assert in remove to match initial hardware state, and to also make
> it work across multiple probe/remove.
I don't understand this part either.. Usually you just power up and init
the registers to a sane state in a device driver probe and on exit just
power down the device.
> >>> Basically I'm wondering how come we need these platform data callbacks
> >>> at all.
> >>
> >> The hardresets are controlled through the
> >> omap_device_assert(deassert)_hardreset functions, and since these are
> >> limited to mach-omap2, we are invoking them through platform data callbacks.
> >
> > Right.. But I'm wondering about the why you need to do this in the
> > driver at all part :)
>
> The initial reset at init time is okay, but hwmod _enable() bails out if
> the resets lines are asserted. This was a change made long time back, I
> believe to deal with the problems around the DSP enabling sequences. As
> such, pm_runtime_get_sync() and put_sync() do not deassert and assert
> the resets.
OK if the hwmod code does not deassert reset lines properly on enable,
then that sounds like a bug that should be fixed instead of adding
device specific work arounds.
Sorry to keep dragging this on a bit longer, but I think we need to
hear Paul's comments on this one.
Regards,
Tony
next prev parent reply other threads:[~2016-01-28 18:32 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 14:11 [PATCH v3 0/3] dra7xx: get pcie working in mainline Kishon Vijay Abraham I
2016-01-14 14:11 ` [PATCH v3 1/3] ARM: DRA7: hwmod: Add reset data for PCIe Kishon Vijay Abraham I
2016-02-08 1:50 ` Paul Walmsley
2016-01-14 14:11 ` [PATCH v3 2/3] ARM: DRA7: add pdata-quirks to do reset of PCIe Kishon Vijay Abraham I
2016-01-15 19:19 ` Suman Anna
2016-01-15 19:22 ` Tony Lindgren
2016-01-15 19:41 ` Suman Anna
2016-01-18 9:12 ` Sekhar Nori
2016-01-27 17:23 ` Tony Lindgren
2016-01-14 14:11 ` [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset Kishon Vijay Abraham I
2016-01-27 17:31 ` Tony Lindgren
2016-01-27 18:16 ` Suman Anna
2016-01-27 18:56 ` Tony Lindgren
2016-01-27 23:16 ` Suman Anna
2016-01-28 18:31 ` Tony Lindgren [this message]
2016-01-28 21:15 ` Suman Anna
2016-02-02 10:40 ` Kishon Vijay Abraham I
2016-02-05 4:19 ` Kishon Vijay Abraham I
2016-02-08 2:48 ` Paul Walmsley
2016-02-08 20:56 ` Suman Anna
2016-02-09 8:49 ` Paul Walmsley
2016-02-09 17:40 ` Suman Anna
2016-02-09 19:36 ` Paul Walmsley
2016-02-10 1:42 ` Suman Anna
2016-02-10 5:38 ` Kishon Vijay Abraham I
2016-02-11 19:27 ` Paul Walmsley
2016-02-11 22:04 ` Suman Anna
2016-02-12 6:49 ` Kishon Vijay Abraham I
2016-02-12 17:20 ` Suman Anna
2016-02-18 14:21 ` Sekhar Nori
2016-02-18 17:23 ` Paul Walmsley
2016-02-18 18:27 ` Suman Anna
2016-02-22 6:18 ` Kishon Vijay Abraham I
2016-02-22 6:31 ` Paul Walmsley
2016-02-22 9:55 ` Kishon Vijay Abraham I
2016-02-23 11:57 ` Kishon Vijay Abraham I
2016-02-23 18:28 ` Paul Walmsley
2016-02-24 6:21 ` Kishon Vijay Abraham I
2016-03-01 8:25 ` Paul Walmsley
2016-03-01 11:55 ` Kishon Vijay Abraham I
2016-03-01 14:43 ` Bjorn Helgaas
2016-03-01 16:55 ` Suman Anna
2016-02-11 20:43 ` Suman Anna
2016-02-12 6:55 ` Kishon Vijay Abraham I
2016-02-10 5:36 ` Kishon Vijay Abraham I
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=20160128183156.GH19432@atomide.com \
--to=tony@atomide.com \
--cc=bhelgaas@google.com \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nsekhar@ti.com \
--cc=paul@pwsan.com \
--cc=richardcochran@gmail.com \
--cc=s-anna@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 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).