1. 11 11月, 2017 1 次提交
    • R
      ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv · f568f6f5
      Rob Herring 提交于
      "usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
      property. This is probably because the binding was the precursor to the phy
      binding.
      
      Fixes the following warning in OMAP dts files:
      
      Warning (phys_property): Missing property '#phy-cells' in node ...
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: "Benoît Cousson" <bcousson@baylibre.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
      Cc: Javier Martinez Canillas <javier@dowhile0.org>
      Cc: linux-omap@vger.kernel.org
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f568f6f5
  2. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      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: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  3. 11 8月, 2017 1 次提交
  4. 26 5月, 2017 1 次提交
  5. 20 5月, 2017 1 次提交
  6. 13 10月, 2015 1 次提交
  7. 21 5月, 2015 1 次提交
  8. 25 3月, 2015 1 次提交
  9. 06 11月, 2014 1 次提交
    • T
      ARM: dts: Add twl keypad map for omap3 EVM · 8cf747f1
      Tony Lindgren 提交于
      Looks like we're still missing the keypad map for EVM.
      Let's add it since we have the binding now available
      for the twl4030_keypad as otherwise we get the following
      errors during the boot:
      
      twl4030_keypad keypad.31: OF: linux,keymap property not defined
      in /ocp/i2c@48070000/twl@48/keypad
      twl4030_keypad keypad.31: Failed to build keymap
      twl4030_keypad: probe of keypad.31 failed with error -2
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      8cf747f1
  10. 16 6月, 2014 1 次提交
    • T
      ARM: dts: Enable twl4030 off-idle configuration for selected omaps · 9188883f
      Tony Lindgren 提交于
      N900 now seems to shut down the external oscillator when hitting
      off-idle.
      
      And Beagle XM seems to have OSC_EN pin connected to allow shutting
      down the oscillator looking at the schematics. The oscillator
      output is cut off in off-idle and you can monitor it from R56 on
      the bottom side of the board near the power jack. Note that for
      beagle we need to also enable the UART wake-up event, the others
      have that enabled in earlier patches.
      
      OMAP37XX EVM (TMDSEVM3730) does not seem to have twl4030 clken
      pin connected, so there is no point trying to enable shutting
      down of the oscillator on it for the extra latency it adds.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      9188883f
  11. 03 6月, 2014 1 次提交
    • T
      ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp · bc10f310
      Tony Lindgren 提交于
      Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
      configured as various panel dpi entries for whatever legacy reasons.
      For device tree based support, let's just configure these properly for
      panel ls037v7dw01 instead of panel dpi.
      
      This patch creates a common file for panel ls037v7dw01, and makes
      boards ldp and omap3-evm to use it.
      
      The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
      controller for the omaps, so let's add a basic configuration for
      the touchscreen also using the default values.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bc10f310
  12. 15 10月, 2013 2 次提交
  13. 28 9月, 2013 1 次提交
  14. 19 6月, 2013 3 次提交
  15. 10 5月, 2013 1 次提交
  16. 09 4月, 2013 3 次提交
    • N
      ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU · a134be34
      Nishanth Menon 提交于
      Define VDD1 regulator in twl4030 DT and mark it as the supply for the
      various OMAP34xx/35xx/36xx/37xx platforms (all use TWL4030 variants with
      VDD1 supplying the CPU).
      
      NOTE: This currently will use I2C1 bus communication path to set the
      voltage in device tree boot. In the legacy non device tree boot, we
      continue to use twl-common.c which bypasses I2C1 bus communication path
      and uses I2C4 bus path using OMAP voltage libraries. We should
      eventually be able to use I2C4 path once we have voltage regulator for
      OMAP which is capable of using the voltage controller/voltage processor
      IP blocks.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Keerthy <j-keerthy@ti.com>
      Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>
      a134be34
    • N
      ARM: dts: OMAP34xx/35xx: Add CPU OPP table · 1e633d71
      Nishanth Menon 提交于
      Add DT OPP table for OMAP34xx/35xx family of devices. This data is
      decoded by OF with of_init_opp_table() helper function.
      
      OPP data here is based on existing opp3xxx_data.c
      
      Since the omap36xx OPP tables would be different from OMAP34xx/35xx,
      introduce an new omap34xx.dtsi for 34xx/35xx specific entries and use
      existing omap3.dtsi as the common dtsi file for all OMAP3 platforms.
      
      This is in preparation to use generic cpufreq-cpu0 driver for device
      tree enabled boot. Legacy non device tree enabled boot continues to
      use omap-cpufreq.c and opp3xxx_data.c.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Keerthy <j-keerthy@ti.com>
      Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>
      1e633d71
    • K
      ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards · ad871c10
      Kishon Vijay Abraham I 提交于
      Add usb otg data node in omap4/omap3 device tree file. Also update
      the node with board specific setting in omapx-<board>.dts file.
      The dt data specifies among others the interface type (ULPI or UTMI),
      mode which is mostly OTG, power that specifies the amount of power
      this can supply when in host mode.
      
      The information about usb otg node is available @
      Documentation/devicetree/bindings/usb/omap-usb.txt
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>
      ad871c10
  17. 08 9月, 2012 1 次提交
  18. 02 7月, 2012 1 次提交
  19. 25 2月, 2012 1 次提交