Messages in this thread | | | Date | Wed, 27 Jan 2016 10:56:49 -0800 | From | Tony Lindgren <> | Subject | Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset |
| |
* 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; } }
Care to explain what exactly the problem with the hwmod code not doing the reset on init?
And why do you need to do another reset in dra7xx_pcie_remove()?
> > 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 :)
Regards,
Tony
| |