1. 13 Jan, 2020 1 commit
  2. 09 Sep, 2019 1 commit
  3. 19 Feb, 2019 2 commits
  4. 10 Jul, 2018 1 commit
  5. 26 Jun, 2018 1 commit
  6. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      
      
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  7. 23 Jan, 2017 1 commit
  8. 20 Nov, 2016 1 commit
    • Kevin Hilman's avatar
      ARM: davinci: PM: fix build when da850 not compiled in · f7715b29
      Kevin Hilman authored
      
      
      Currently, suspend/resume support is only available on da850 platforms,
      and the platform PM code has dependencies on da850 functions.  However,
      CONFIG_SUSPEND might be enabled even when da850 support is not, causing
      build failure:
      
      arch/arm/mach-davinci/built-in.o: In function `davinci_pm_init':
      pm_domain.c:(.init.text+0x1fb8): undefined reference to `da8xx_get_mem_ctlr'
      pm_domain.c:(.init.text+0x20b0): undefined reference to `da8xx_syscfg1_base'
      
      Fix this by only building the PM core when da850 is enabled.
      Reported-by: default avatarSekhar Nori <nsekhar@ti.com>
      Fixes: aa9aa1ec
      
       ("ARM: davinci: PM: rework init, remove platform device")
      Signed-off-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      f7715b29
  9. 14 Apr, 2016 1 commit
  10. 20 Jan, 2015 1 commit
  11. 17 Mar, 2014 1 commit
  12. 18 Jun, 2013 1 commit
  13. 08 Apr, 2013 1 commit
  14. 29 Oct, 2012 1 commit
  15. 01 Jul, 2012 1 commit
    • Kevin Hilman's avatar
      ARM: davinci: add runtime PM support for clock management · ce9dcb87
      Kevin Hilman authored
      
      
      Add runtime PM core support to davinci by using the pm_clk
      infrastructure of the PM core.
      
      When runtime PM is enabled, the davinci runtime PM implementation will
      use the pm_clk layer to enable/disable clocks on demand.  When runtime
      PM is disabled, the pm_clk core will automatically enable clocks when
      the driver is bound and disable clocks when the driver is unbound.
      
      Cc: Mark A. Greer <mgreer@animalcreek.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      [nsekhar@ti.com: pruned list of header file includes and removed some
      debug code]
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      ce9dcb87
  16. 16 Nov, 2011 1 commit
  17. 22 Aug, 2011 2 commits
  18. 24 Sep, 2010 3 commits
  19. 21 Jun, 2010 3 commits
  20. 04 Feb, 2010 2 commits
    • Nageswari Srinivasan's avatar
      davinci: add CDCE949 support on DM6467 EVM · 77a92c71
      Nageswari Srinivasan authored
      
      
      This patch adds the CDCE949 reference oscillator to
      the davinci clock list.
      
      On the DM6467T EVM, the CDCE949 is responsible for
      generating the pixel clock for display. On the DM6467
      EVM, this pixel clock was being obtained from an
      internal source. This is not possible on the DM6467T
      EVM because of the presence of a 33MHz oscillator.
      
      The TSIF module also requires the CDCE949 to generate
      the data clocks.
      
      The actual clock definitions will be added by patches
      adding support for DM6467T VPIF and TSIF. This patch
      mearly lays the foundation for that work.
      Signed-off-by: default avatarNageswari Srinivasan <nageswari@ti.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      77a92c71
    • Sekhar Nori's avatar
      davinci: add power management support · efc1bb8a
      Sekhar Nori authored
      
      
      This patch adds core power management (suspend-to-RAM)
      support for DaVinci SoCs.
      
      The code depends on the the "deepsleep" feature to suspend
      the SoC and saves power by gating the input clock.
      
      The wakeup can be based on an external event as supported
      by the SoC.
      
      Assembly code (in sleep.S) is added to aid gating DDR2
      clocks. Code doing this work should not be accessing DDR2.
      The assembly code is relocated to SRAM by the code in pm.c
      
      The support has been validated on DA850/OMAP-L138 only
      though the code is (hopefully) generic enough that other
      SoCs supporting deepsleep feature simply requires SoC
      specific code to start using this driver.
      
      Note that all the device drivers don't support suspend/resume
      still and are being worked on.
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      efc1bb8a
  21. 25 Nov, 2009 3 commits
  22. 26 Aug, 2009 5 commits
    • Sudhakar Rajashekhara's avatar
      davinci: Add support for DA850/OMAP-L138 EVM board · 0fbc5592
      Sudhakar Rajashekhara authored
      
      
      Add support for the DA850/OMAP-L138 Evaluation Module (EVM)
      from TI.  The EVM has User Interface (UI) card which contains
      various devices. This UI card can be connected to the base
      board. Support for all the devices on the UI card and ones on
      the EVM will be added in subsequent patches.
      
      The EVM schematics are not available publicly yet; but should
      be available soon.
      
      A new defconfig for this board has been added mainly because
      the DA830/OMAP-L137 defconfig forces writethrough cache mode
      which is not required on DA850/OMAP-L138.
      
      This patch has been boot tested on DA850/OMAP-L138 EVM
      using ramdisk as filesystem.
      Signed-off-by: default avatarSudhakar Rajashekhara <sudhakar.raj@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      0fbc5592
    • Sudhakar Rajashekhara's avatar
      davinci: Add base DA850/OMAP-L138 SoC support · e1a8d7e2
      Sudhakar Rajashekhara authored
      The DA850/OMAP-L138 is a new SoC from TI in the same family as
      DA830/OMAP-L137.
      
      Major changes include better support for power management,
      support for SATA devices and McBSP (same IP as DM644x).
      
      DA850/OMAP-L138 documents are available at
      http://focus.ti.com/docs/prod/folders/print/omap-l138.html
      
      .
      Signed-off-by: default avatarSudhakar Rajashekhara <sudhakar.raj@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      e1a8d7e2
    • Mark A. Greer's avatar
      davinci: da8xx: Add support for DA830/OMAP-L137 EVM board · 8593790d
      Mark A. Greer authored
      
      
      Add support for the DA830/OMAP-L137 Evaluation Module (EVM)
      from TI.  The EVM has User Interface (UI) and Audio cards
      that can be connected which contain various devices.
      Support for those devices and ones on the EVM will be
      added in subsequent patches.
      
      Additional generalizations for future SoCs in da8xx family done by
      Sudhakar Rajashekhara and Sekhar Nori.
      Signed-off-by: default avatarSteve Chen <schen@mvista.com>
      Signed-off-by: default avatarMark A. Greer <mgreer@mvista.com>
      Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      8593790d
    • Mark A. Greer's avatar
      davinci: da8xx: Add base DA830/OMAP-L137 SoC support · 55c79a40
      Mark A. Greer authored
      
      
      The da830/omap l137 is a new SoC from TI that is similar
      to the davinci line.  Since its so similar to davinci,
      put the support for the da830 in the same directory as
      the davinci code.
      
      There are differences, however.  Some of those differences
      prevent support for davinci and da830 platforms to work
      in the same kernel binary.  Those differences are:
      
      1) Different physical address for RAM.  This is relevant
         to Makefile.boot addresses and PHYS_OFFSET.  The
         Makefile.boot issue isn't truly a kernel issue but
         it means u-boot won't work with a uImage including
         both architectures.  The PHYS_OFFSET issue is
         addressed by the "Allow for runtime-determined
         PHYS_OFFSET" patch by Lennert Buytenhek but it
         hasn't been accepted yet.
      
      2) Different uart addresses.  This is only an issue
         for the 'addruart' assembly macro when CONFIG_DEBUG_LL
         is enabled.  Since the code in that macro is called
         so early (e.g., by _error_p in kernel/head.S when
         the processor lookup fails), we can't determine what
         platform the kernel is running on at runtime to use
         the correct uart address.
      
      These areas have compile errors intentionally inserted
      to indicate to the builder they're doing something wrong.
      
      A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added
      to distinguish between a true davinci architecture and
      the da830 architecture.
      
      Note that the da830 currently has an issue with writeback
      data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be
      enabled when building a da830 kernel.
      
      Additional generalizations for future SoCs in the da8xx family done by
      Sudhakar Rajashekhara and Sekhar Nori.
      Signed-off-by: default avatarSteve Chen <schen@mvista.com>
      Signed-off-by: default avatarMikhail Cherkashin <mcherkashin@ru.mvista.com>
      Signed-off-by: default avatarMark A. Greer <mgreer@mvista.com>
      Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      55c79a40
    • Sandeep Paulraj's avatar
      davinci: Adding DM365 entries to Makefile/Kconfig/defconfig · a46e9e40
      Sandeep Paulraj authored
      
      
      This patch does the following
      1) Adds entries to davinci_all_defconfig for DM365
      2) Adds entries to the Makefile for DM365
      3) Adds entries for DM365 in the Kconfig
      Signed-off-by: default avatarSandeep Paulraj <s-paulraj@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      a46e9e40
  23. 28 May, 2009 2 commits
  24. 26 May, 2009 3 commits
    • Mark A. Greer's avatar
      davinci: Support JTAG ID register at any address · b9ab1279
      Mark A. Greer authored
      
      
      The Davinci cpu_is_davinci_*() macros use the SoC part number
      and variant retrieved from the JTAG ID register to determine the
      type of cpu that the kernel is running on.  Currently, the code to
      read the JTAG ID register assumes that the register is always at
      the same base address.  This isn't true on some newer SoCs.
      
      To solve this, have the SoC-specific code set the JTAG ID register
      base address in soc_info structure and add a 'cpu_id' member to it.
      'cpu_id' will be used by the cpu_is_davinci_*() macros to match
      the cpu id.  Also move the info used to identify the cpu type into
      the SoC-specific code to keep all SoC-specific code together.
      
      The common code will read the JTAG ID register, search through
      an array of davinci_id structures to identify the cpu type.
      Once identified, it will set the 'cpu_id' member of the soc_info
      structure to the proper value and the cpu_is_davinci_*() macros
      will now work.
      Signed-off-by: default avatarMark A. Greer <mgreer@mvista.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      b9ab1279
    • Mark A. Greer's avatar
      davinci: Encapsulate SoC-specific data in a structure · 79c3c0b7
      Mark A. Greer authored
      
      
      Create a structure to encapsulate SoC-specific information.
      This will assist in generalizing code so it can be used by
      different SoCs that have similar hardware but with minor
      differences such as having a different base address.
      
      The idea is that the code for each SoC fills out a structure
      with the correct information.  The board-specific code then
      calls the SoC init routine which in turn will call a common
      init routine that makes a copy of the structure, maps in I/O
      regions, etc.
      
      After initialization, code can get a pointer to the structure
      by calling davinci_get_soc_info().  Eventually, the common
      init routine will make a copy of all of the data pointed to
      by the structure so the original data can be made __init_data.
      That way the data for SoC's that aren't being used won't consume
      memory for the entire life of the kernel.
      
      The structure will be extended in subsequent patches but
      initially, it holds the map_desc structure for any I/O
      regions the SoC/board wants statically mapped.
      Signed-off-by: default avatarMark A. Greer <mgreer@mvista.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      79c3c0b7
    • Kevin Hilman's avatar
      davinci: DM646x: add base SoC and board support · e38d92fd
      Kevin Hilman authored
      
      
      Add support for DM646x SoC (a.k.a DaVinci HD) and its Evalution
      Module (EVM.)
      
      Original support done by Sudhakar Rajashekhara.
      Signed-off-by: default avatarSudhakar Rajashekhara <sudhakar.raj@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      e38d92fd