lkml.org 
[lkml]   [2016]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2016-01-27 20:41    [W:4.296 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site