1. 23 Jan, 2020 2 commits
  2. 16 Nov, 2019 3 commits
  3. 09 Nov, 2019 2 commits
  4. 29 Sep, 2019 1 commit
  5. 26 Sep, 2019 5 commits
  6. 23 Sep, 2019 1 commit
  7. 21 Sep, 2019 2 commits
  8. 16 Feb, 2019 2 commits
  9. 17 Jan, 2019 1 commit
  10. 10 Oct, 2018 2 commits
  11. 06 Oct, 2018 1 commit
    • Tony Lindgren's avatar
      Help needed: Trying to find out the cause of the freezes. · 40a38c35
      Tony Lindgren authored
      Well for the idle freezing issue, curiously the old
      "disable internal dll" trick seems to work. At least for
      me the system keeps running just fine idling for several
      hours.
      
      Also, looks like we have SDRAM_CONFIG ROWSIZE bits [9:7] set
      to 15 while it should be 16 for 8Gb memory. But I think
      that is just cosmetic, not sure if that is actually used.
      
      Anyways, care to test with the following hack with internal
      dll disabled and ROWSIZE fixed?
      
      If that works for the idle system problem, then we probably
      have some DLL timing related value misconfigured.
      
      Regards,
      
      Tony
      40a38c35
  12. 21 Sep, 2018 2 commits
  13. 08 Aug, 2018 2 commits
  14. 22 Jul, 2018 4 commits
    • Nishanth Menon's avatar
      ARM: OMAP5: Enable support for AVS0 for OMAP5 production devices · 21d5cc02
      Nishanth Menon authored
      OMAP5432 did go into production with AVS class0 registers which were
      mutually exclusive from AVS Class 1.5 registers.
      
      Most OMAP5-uEVM boards use the pre-production Class1.5 which has
      production efuse registers set to 0. However on production devices,
      these are set to valid data.
      
      scale_vcore logic is already smart enough to detect this and use the
      "Nominal voltage" on devices that do not have efuse registers populated.
      
      On a test production device populated as follows:
      MPU OPP_NOM:
      => md.l 0x04A0021C4 1
      4a0021c4: 03a003e9                               ....
      (0x3e9 = 1.01v) vs nom voltage of 1.06v
      MPU OPP_HIGH:
      => md.l 0x04A0021C8 1
      4a0021c8: 03400485                               ..@.
      
      MM OPP_NOM:
      => md.l 0x04A0021A4 1
      4a0021a4: 038003d4                               ....
      (0x3d4 = 980mV) vs nom voltage of 1.025v
      MM OPP_OD:
      => md.l 0x04A0021A8 1
      4a0021a8: 03600403                               ..`.
      
      CORE OPP_NOM:
      => md.l 0x04A0021D8 1
      4a0021d8: 000003cf                               ....
      (0x3cf = 975mV) vs nom voltage of 1.040v
      
      Since the efuse values are'nt currently used, we do not regress on
      existing pre-production samples (they continue to use nominal voltage).
      
      But on boards that do have production samples populated, we can leverage
      the optimal voltages necessary for proper operation.
      
      Tested on:
      a) 720-2644-001 OMAP5UEVM with production sample.
      b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.
      
      Data based on OMAP5432 Technical reference Manual SWPU282AF (May
      2012-Revised Aug 2016)
      
      NOTE: All collaterals on OMAP5432 silicon itself seems to have been
      removed from ti.com, though EVM details are still available:
      http://www.ti.com/tool/OMAP5432-EVMSigned-off-by: default avatarNishanth Menon <nm@ti.com>
      21d5cc02
    • Nishanth Menon's avatar
      ARM: OMAP5: Remove OPP_LOW Definitions for ES2.0 · 7f7a98d8
      Nishanth Menon authored
      ES2.0 descopes OPP_LOW definition. So remove it from macros defined.
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Reviewed-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      7f7a98d8
    • Matthijs van Duin's avatar
      arm: omap-common: Fix typo in CONFIG_OMAP54XX guard · 41ef538c
      Matthijs van Duin authored
      Some initialization was unintentionally being skipped on omap5.
      
      Fixes: f5af0827 ("arm: omap-common: Guard some parts of the code with CONFIG_OMAP44XX/OMAP54XX")
      Signed-off-by: Matthijs van Duin's avatarMatthijs van Duin <matthijsvanduin@gmail.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      41ef538c
    • H. Nikolaus Schaller's avatar
  15. 21 Jul, 2018 7 commits
  16. 01 Jul, 2018 3 commits