1. 09 May, 2013 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c · b1dd11d6
      Tony Lindgren authored
      Commit 6770b211 (ARM: OMAP2+: Export SoC information to userspace)
      had some broken return value handling as noted by Russell King:
      
      +       soc_dev = soc_device_register(soc_dev_attr);
      +       if (IS_ERR_OR_NULL(soc_dev)) {
      +               kfree(soc_dev_attr);
      +               return;
      +       }
      +
      +       parent = soc_device_to_device(soc_dev);
      +       if (!IS_ERR_OR_NULL(parent))
      +               device_create_file(parent, &omap_soc_attr);
      
      This is nonsense.  For the first, IS_ERR() is sufficient.  For the second,
      tell me what error checking is required in the return value of this
      function:
      
      struct device *soc_device_to_device(struct soc_device *soc_dev)
      {
              return &soc_dev->dev;
      }
      
      when you've already determined that the passed soc_dev is a valid pointer.
      If you read the comments against the prototype:
      
      /**
       * soc_device_to_device - helper function to fetch struct device
       * @soc: Previously registered SoC device container
       */
      struct device *soc_device_to_device(struct soc_device *soc);
      
      if "soc" is valid, it means the "previously registered SoC device container"
      must have succeeded and that can only happen if the struct device has been
      registered.  Ergo, there will always be a valid struct device pointer for
      any registered SoC device container.  Therefore, if soc_device_register()
      succeeds, then the return value from soc_device_to_device() will always be
      valid and no error checking of it is required.
      
      Simples.  The rule as ever applies here: get to know the APIs your using
      and don't fumble around in the dark hoping that you'll get this stuff
      right.
      
      Fix it as noted by Russell.
      Reported-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      b1dd11d6
  2. 08 May, 2013 1 commit
  3. 08 Apr, 2013 2 commits
  4. 19 Mar, 2013 1 commit
  5. 01 Feb, 2013 1 commit
  6. 31 Jan, 2013 1 commit
  7. 14 Nov, 2012 1 commit
  8. 08 Nov, 2012 1 commit
  9. 20 Sep, 2012 1 commit
  10. 12 Sep, 2012 2 commits
    • Tony Lindgren's avatar
      ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ · dbc04161
      Tony Lindgren authored
      As the plat and mach includes need to disappear for single zImage work,
      we need to remove plat/hardware.h.
      
      Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.
      
      The old plat/hardware.h already has omap1 only defines, so it gets moved
      to mach/hardware.h for omap1. For omap2+, we use the local soc.h
      that for now just includes the related SoC headers to keep this patch more
      readable.
      
      Note that the local soc.h still includes plat/cpu.h that can be dealt
      with in later patches. Let's also include plat/serial.h from common.h for
      all the board-*.c files. This allows making the include files local later
      on without patching these files again.
      
      Note that only minimal changes are done in this patch for the
      drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
      patches are needed to eventually remove cpu_is_omap usage in the drivers.
      
      Also only minimal changes are done to sound/soc/omap/* to remove the
      unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
      no need to include omap44xx.h.
      
      While at it, also sort some of the includes in the standard way.
      
      Cc: linux-watchdog@vger.kernel.org
      Cc: alsa-devel@alsa-project.org
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Acked-by: default avatarWim Van Sebroeck <wim@iguana.be>
      Acked-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      dbc04161
    • Paul Walmsley's avatar
      ARM: OMAP: unwrap strings · 7852ec05
      Paul Walmsley authored
      Find and unwrap wrapped strings in the style:
      
      	pr_debug("clockdomain: hardware cannot set/clear wake up of "
      		 "%s when %s wakes up\n", clkdm1->name, clkdm2->name);
      
      Keeping these strings contiguous seems to be the current Linux kernel
      policy.
      
      The offending lines were found with the following command:
      
          pcregrep -rnM '"\s*$\s*"' arch/arm/*omap*
      
      While here, some messages have been clarified, some pr_warning(
      ... calls have been converted to pr_warn( ..., and some printk(KERN_*
      ... have been converted to pr_*.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      7852ec05
  11. 09 Jul, 2012 1 commit
  12. 05 Jul, 2012 1 commit
  13. 11 May, 2012 1 commit
    • Mark A. Greer's avatar
      arm: omap3: am35x: Don't mark missing features as present · 1ce02996
      Mark A. Greer authored
      The Chip Identification register on the am35x family of SoCs
      has bits 12, 7:5, and 3:2 marked as reserved and are read as
      zeroes.  Unfortunately, on other omap SoCs, a 0 bit means a
      feature is "Full Use" so the OMAP3_CHECK_FEATURE() macro
      called by omap3_check_features() will incorrectly interpret
      those zeroes to mean that a feature is present even though it
      isn't.  To fix that, the feature bits that are incorrectly
      set (namely, OMAP3_HAS_IVA and OMAP3_HAS_ISP) need to be
      cleared after all of the calls to OMAP3_CHECK_FEATURE() in
      omap3_check_features() are made.
      Signed-off-by: default avatarMark A. Greer <mgreer@animalcreek.com>
      [khilman@ti.com: use soc_is_am35xx() instead of cpu_is_am35xx()]
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      1ce02996
  14. 10 May, 2012 1 commit
  15. 09 May, 2012 1 commit
  16. 05 Mar, 2012 1 commit
  17. 29 Feb, 2012 1 commit
  18. 19 Dec, 2011 2 commits
  19. 13 Dec, 2011 5 commits
  20. 17 Nov, 2011 1 commit
  21. 07 Oct, 2011 1 commit
    • Paul Walmsley's avatar
      ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection · b02b9172
      Paul Walmsley authored
      The way that we detect which OMAP3 chips support I/O wakeup and
      software I/O chain clock control is broken.
      
      Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
      than the AM3505/3517.  The TI81xx family of SoCs are at present
      considered to be OMAP3 SoCs, but don't support I/O wakeup.  To resolve
      this, convert the existing blacklist approach to an explicit,
      whitelist support, in which only SoCs which are known to support I/O
      wakeup are listed.  (At present, this only includes OMAP34xx,
      OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)
      
      Also, the current code incorrectly detects the presence of a
      software-controllable I/O chain clock on several chips that don't
      support it.  This results in writes to reserved bitfields, unnecessary
      delays, and console messages on kernels running on those chips:
      
          http://www.spinics.net/lists/linux-omap/msg58735.html
      
      Convert this test to a feature test with a chip-by-chip whitelist.
      
      Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
      and doing some testing to help isolate the cause.  Thanks to Steve
      Sakoman <sakoman@gmail.com> for catching a bug in the first version of
      this patch.  Thanks to Russell King <linux@arm.linux.org.uk> for
      comments.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Dave Hylands <dhylands@gmail.com>
      Cc: Steve Sakoman <sakoman@gmail.com>
      Tested-by: default avatarSteve Sakoman <sakoman@gmail.com>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      b02b9172
  22. 14 Sep, 2011 5 commits
  23. 13 Sep, 2011 1 commit
    • Paul Walmsley's avatar
      OMAP3: id: remove identification codes that only correspond to marketing names · 1f1b0353
      Paul Walmsley authored
      The OMAP3505/AM3505 appears to be based on the same silicon as the
      OMAP3517/AM3517, with some features disabled via eFuse bits.  Follow
      the same practice as OMAP3430 and identify these devices internally as
      part of the OMAP3517/AM3517 family.
      
      The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon
      as the OMAP3430, with some features disabled via eFuse bits.  Identify
      these devices internally as part of the OMAP3430 family.
      
      Remove the old OMAP35XX_CLASS, which actually covered two very different
      chip families.  The OMAP3503/3515/3525/3530 chips will now be covered by
      OMAP343X_CLASS, since the silicon appears to be identical.  For the
      OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS.
      
      Thanks to Tony Lindgren <tony@atomide.com> for some help with the second
      revision of this patch.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Sanjeev Premi <premi@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Tested-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
      Tested-by: default avatarAbhilash Koyamangalath <abhilash.kv@ti.com>
      1f1b0353
  24. 08 Jul, 2011 2 commits
  25. 14 Mar, 2011 1 commit
  26. 17 Feb, 2011 1 commit
  27. 16 Feb, 2011 1 commit
  28. 08 Oct, 2010 1 commit
    • Paul Walmsley's avatar
      OMAP: control: move plat-omap/control.h to mach-omap2/control.h · 4814ced5
      Paul Walmsley authored
      Only OMAP2+ platforms have the System Control Module (SCM) IP block.
      In the past, we've kept the SCM header file in plat-omap.  This has
      led to abuse - device drivers including it; includes being added that
      create implicit dependencies on OMAP2+ builds; etc.
      
      In response, move the SCM headers into mach-omap2/.
      
      As part of this, remove the direct SCM access from the OMAP UDC
      driver.  It was clearly broken.  The UDC code needs an indepth review for
      use on OMAP2+ chips.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Cory Maccarrone <darkstar6262@gmail.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      4814ced5