21 Oct, 2014

1 commit


04 Aug, 2014

1 commit


16 Apr, 2014

1 commit


10 Mar, 2014

2 commits


09 Mar, 2014

1 commit


07 Mar, 2014

2 commits


14 Feb, 2014

19 commits


14 Jun, 2013

3 commits

  • Recent commit from Greg (OPP Table fix for 720MHZ and ZCE
    support) added OPP120 support for PG 2.x.

    OPP120 support needs to be disabled when the board is booted and
    running at OPP50. This is as per the Advisory 1.0.15 (ARM Cortex-A8:
    OPP50 Operation on MPU Domain Not Supported)

    Voltage checked here are Core Voltage and not MPU. Hence, When here
    correct the preprocessors to indicate correct voltages.

    As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
    (SPRS717F) APRIL 2013 available at
    http://www.ti.com/lit/ds/symlink/am3359.pdf

    Table 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
    ZCE packages respectively

    Signed-off-by: Hebbar Gururaja

    Hebbar Gururaja
     
  • Current OPP table excludes 720MHz OPPs for ES 2.0 and ES 2.1. It also
    excludes an 300MHz at 1.1V operating point required for ZCE support on
    ES 2.1.
    This patch implements support for the same.

    As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
    (SPRS717F) APRIL 2013 available at
    http://www.ti.com/lit/ds/symlink/am3359.pdf

    Table 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
    ZCE packages respectively

    [ Hebbar Gururaja]:
    - Add Link to Documentation and reference table.
    - Fix merge issue and remove whitespace warning

    Signed-off-by: Greg Guyotte
    Signed-off-by: Hebbar Gururaja

    Greg Guyotte
     
  • After random iteration, uart standby using (gpio pin configs) hangs.

    Upon deep observation (and lots of debug prints), it was observed that
    the GPIO Rising/Falling detect registers were cleared (IRQ disabled)
    before system entered standby. Any UART activity (key press) was not
    detected.

    This registers were properly setup by request_irq call from
    am33xx_pm_prepare_late() (initial suspend stage).

    However, driver suspend calls (.suspend()) come in later stage and due
    to some race condition, gpio_mask_irq() masks/clears above registers.

    The fix is to call the standby setup function (which calls request_irq)
    at final stage just before the actual suspend call.

    This fix was tested by placing the system under standby stress test for
    more than 20 Hours.

    Signed-off-by: Hebbar Gururaja

    Hebbar Gururaja
     

05 Jun, 2013

2 commits

  • Add OPP table for MPU voltage domain.

    Changes from PG2.0:
    1. The Operating voltage for Nitro Mode is 1.35V
    2. PG 2.1 SoC has a new efuse sma register which describes the device's
    ARM maximum frequency capabilities and package type. Upon parsing this
    register, the supported maximum frequency is obtained.
    Note:
    If this register is not populated (mpu max freq field is 0), then we
    revert back to PG 2.0 OPP list.

    Signed-off-by: Hebbar Gururaja

    Hebbar Gururaja
     
  • This reverts commit ee9dfd8d729d3e7b5ce9e404a0e87f27f6f79135.

    This patch checks for the package type for checking the supported opp
    bits & also if the bits are set, the opp table is updated.
    However, checking package type bit is not required & also, the opp bit
    checking must be reversed.

    A fix for the same will follow after this commit

    Hebbar Gururaja
     

29 May, 2013

2 commits

  • As per Advisory 1.0.15 (ARM Cortex-A8: OPP50 Operation on MPU Domain Not
    Supported), when the board is booted with OPP50, reliable operation is
    not guaranteed for OPP greater than OPP100 (OPP120, TURBO, NITRO).

    So, Check if the board is booted at OPP50 voltage & if yes, disable
    higher OPP (OPP120, TURBO, NITRO).

    Signed-off-by: Hebbar Gururaja

    Hebbar Gururaja
     
  • Add OPP table for MPU voltage domain.

    Changes from PG2.0:
    1. The Operating voltage for Nitro Mode is 1.35v
    2. PG 2.1 SoC has a new efuse sma register which describes the device's
    ARM maximum frequency capabilities and package type. Upon parsing this
    register, the supported maximum frequency is obtained.
    Note:
    If this register is not populated or the data is invalid (package type),
    then we revert back to PG 2.0 OPP list.

    Signed-off-by: Hebbar Gururaja

    Hebbar Gururaja
     

02 May, 2013

1 commit

  • Errata Titles:
    i103: Delay needed to read some GP timer, WD timer and sync timer
    registers after wakeup (OMAP3/4)
    i767: Delay needed to read some GP timer registers after wakeup (OMAP5)

    Description (i103/i767):
    If a General Purpose Timer (GPTimer) is in posted mode
    (TSICR [2].POSTED=1), due to internal resynchronizations, values read in
    TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
    (L4) goes from stopped to active may not return the expected values. The
    most common event leading to this situation occurs upon wake up from
    idle.

    GPTimer non-posted synchronization mode is not impacted by this
    limitation.

    Workarounds:
    1). Disable posted mode
    2). Use static dependency between timer clock domain and MPUSS clock
    domain
    3). Use no-idle mode when the timer is active

    Workarounds #2 and #3 are not pratical from a power standpoint and so
    workaround #1 has been implemented. Disabling posted mode adds some CPU
    overhead for configuring and reading the timers as the CPU has to wait
    for accesses to be re-synchronised within the timer. However, disabling
    posted mode guarantees correct operation.

    Please note that it is safe to use posted mode for timers if the counter
    (TCRR) and capture (TCARx) registers will never be read. An example of
    this is the clock-event system timer. This is used by the kernel to
    schedule events however, the timers counter is never read and capture
    registers are not used. Given that the kernel configures this timer
    often yet never reads the counter register it is safe to enable posted
    mode in this case. Hence, for the timer used for kernel clock-events,
    posted mode is enabled by overriding the errata for devices that are
    impacted by this defect.

    For drivers using the timers that do not read the counter or capture
    registers and wish to use posted mode, can override the errata and
    enable posted mode by making the following function calls.

    __omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
    __omap_dm_timer_enable_posted(timer);

    Both dmtimers and watchdogs are impacted by this defect this patch only
    implements the workaround for the dmtimer. Currently the watchdog driver
    does not read the counter register and so no workaround is necessary.

    Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
    using a GP timer as a clock-source timer to guarantee correct operation.
    This is not necessary for OMAP24xx devices but the default clock-source
    timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
    and so should not have any impact. This should be re-visited for future
    devices if this errata is fixed.

    Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
    devices.

    Signed-off-by: Jon Hunter
    Acked-by: Santosh Shilimkar
    [hvaibhav@ti.com: Backported to v3.2 PSP kernel, also merged
    commit 7b44cf2c15f (ARM: OMAP: Fix timer posted mode support)]
    Signed-off-by: Vaibhav Hiremath

    Jon Hunter
     

17 Apr, 2013

1 commit


16 Apr, 2013

2 commits


04 Apr, 2013

1 commit


01 Mar, 2013

1 commit