lkml.org 
[lkml]   [2015]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 2/4] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER
    From
    Hi Roger,

    On Tue, Feb 17, 2015 at 9:12 AM, Roger Quadros <rogerq@ti.com> wrote:
    >
    > Can you use the following wording from TRM instead?
    >
    > as per am335x TRM (spruh73i.pdf), section 7.1.3.3.8.3.2
    >
    > The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
    > even though the access is defined as asynchronous, and no GPMC_CLK clock
    > is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
    > for the GPMC clock, so it must be programmed to define the
    > correct WAITMONITORINGTIME delay.


    Verbatim? Sure can. Gonna do that with a rebase to 3.19, I guess.

    >
    > Instead of this can we explicitly set the GPMC_CLK divider to 1 and hence
    > corresponding divider bits to 0 in the asynchronous case?
    > This is because the previously calculated "div" depends on synchronous clock which
    > might not be properly initialized for asynchronous devices.


    No, we shouldn't. If WAITREADMONITORING and/or WAITWRITEMONITORING is
    enabled, sync_clk must be set in order to use WAITMONITORINGTIME
    correctly. If it's not explicitly set, it's set to 0, which yields div
    1 anyways.
    The reason being that a fixed divider of 1 will limit a user's ability
    to prolong the #WAIT-deassert --> *access delay for no good reason. If
    working with a slow device, this will inconvenience users.

    >
    > AFAIK t->sync_clk is always 0 for asynchronous devices and gpmc_calc_divider(0)
    > will return 1 and your patch will work but still we shouldn't depend on sync_clk for
    > asynchronous devices so let's set this explicitly.


    See above. Hardware depends on divider, divider is set by sync_clk, so
    we shouldn't limit what a user can program in DT.
    Having said that, I'm not aware that sync_clk is always 0 for async
    devices. The code always parses it and sets the appropriate field in
    gpmc_t, which is passed to gpmc_cs_set_timings.
    Now, there is generally a lack of checking for optional/required DT
    properties, so I didn't add extra checking.

    Regards,

    Robert


    \
     
     \ /
      Last update: 2015-02-17 15:01    [W:6.492 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site