* Suman Anna [off-list ref] [160127 10:17]:

On 01/27/2016 11:31 AM, Tony Lindgren wrote:

quoted

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()?

quoted

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