summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/omap3-sb-t35.dtsi
AgeCommit message (Collapse)AuthorFilesLines
2021-10-11ARM: dts: omap: Fix boolean properties gpmc,cycle2cycle-{same|diff}csenRoger Quadros1-2/+2
gpmc,cycle2cycle-{same|diff}csen are boolean properties. Fix them to prevent dtbs_check errors. Signed-off-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-05-15ARM: dts: omap: fix OMAP3 CM-T3x OF graph video connectorsRob Herring1-1/+1
The OMAP3 CM-T3x based boards define 2 /connector nodes for S-Video and DVI output. However, since they have the same node name, the S-Video connector overwritten. This leaves a dangling graph connection which gives the following warning: arch/arm/boot/dts/omap3-sbc-t3517.dtb: Warning (graph_endpoint): /ocp@68000000/dss@48050000/encoder@48050c00/port/endpoint: graph connection to node '/connector/port/endpoint' is not bidirectional Fix this by renaming the nodes to s-video-connector and dvi-connector. Cc: "BenoƮt Cousson" <bcousson@baylibre.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
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: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-26ARM: dts: omap: Add generic compatible string for I2C EEPROMJavier Martinez Canillas1-1/+1
The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2017-05-19ARM: dts: omap3: Remove 'enable-active-low' propertyFabio Estevam1-1/+0
Property 'enable-active-low' does not exist. Only 'enable-active-high' is valid, and when this property is absent the gpio regulator will act as active low by default. So remove the unexisting 'enable-active-low' property. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2016-06-29ARM: dts: sbc-t3x30: remove unneded unit namesJavier Martinez Canillas1-4/+4
This patch fixes the following DTC warnings for omap3-sbc-t3517.dtb, omap3-sbc-t3530.dtb and omap3-sbc-t3730.dtb: "encoder@0 has a unit name, but no reg property" "endpoint@0 has a unit name, but no reg property" "connector@0 has a unit name, but no reg property" Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-11-24ARM: dts: sbc-t3x30: add audio supportDmitry Lifshitz1-0/+16
Add audio related DT nodes Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-11-22ARM: dts: sb-t35: add EEPROM supportDmitry Lifshitz1-0/+20
Add at24 EEPROM chip support. Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-11-11ARM: dts: sbc-t3x: add DVI display dataDmitry Lifshitz1-0/+49
Add DSS related pinmux and display data nodes required to support DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517. Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-11-04ARM: dts: Use better omap GPMC timings for LAN9220Tony Lindgren1-18/+23
With the GPMC warnings now enabled, I noticed the LAN9220 timings can overflow the GPMC registers with 200MHz L3 speed. Earlier we were just skipping the bad timings and would continue with the bootloader timings. Now we no longer allow to continue with bad timings as we have the timings in the .dts files. We could start using the GPMC clock divider, but let's instead use the u-boot timings that are known to be working and a bit faster. These are basically the u-boot NET_GPMC_CONFIG[1-6] defines deciphered. Except that we don't set gpmc,burst-length as that's only partially configured and does not seem to work if fully enabled. [tony@atomide.com: updated to remove gpmc,burst-length] Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-04-23ARM: dts: Fix GPMC timings for LAN9220Tony Lindgren1-11/+8
I've noticed occasional random oopsing on my gateway machine since I upgraded it to use device tree based booting. As this machine has worked reliably before that for a few years, pretty much the only difference was narrowed down to the GPMC timings. Turns out that for legacy based booting we are using bootloader timings for GPMC for smsc911x. With device tree we are passing the timings in the .dts file, and the device tree timings are not quite suitable for LAN9920. Enabling DEBUG in gpmc.c I noticed that the device tree configured timings are different from the the known working bootloader timings. So let's fix the timings to match the bootloader timings when looked at the gpmc dmesg output with DEBUG enabled. The changes were done by multiplying the bootloader tick values by six to get the nanosecond value for device tree. This is not generic from the device point of view as the calculations should be based on the device timings. Anyways, further improvments can be done based on the timings documentation for LAN9220. But let's first get things to a known good working state. Note that we still need to change the timings also for sb-t35 also as it has two LAN9220 instances on GPMC and we can currently include the generic timings only once. Also note that any boards that have LAN9221 instead of LAN9220 should be updated to use omap-gpmc-smsc9221.dtsi instead of omap-gpmc-smsc911x.dtsi. The LAN9221 timings are different from LAN9220 timings. Cc: Christoph Fritz <chf.fritz@googlemail.com> Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Cc: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-04-23ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device treeTony Lindgren1-16/+2
Looks like we have wrong GPMC timings we have for the cm-t and sbc-t boards. This can cause occasional strange errors with at least doing an rsync of large files or doing apt-get dist-upgrade. Let's fix the issue in two phases. First let's simplify cm-t and sbc-t to use the shared omap-gpmc-smsc911x.dtsi to avoid fixing the issue in multiple places. Then we can fix the timings in a single place with a follow-up patch. Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-03-01ARM: dts: sb-t35: fix Ethernet power supplyDmitry Lifshitz1-2/+16
SB-T35 baseboard features SMSC9220 Ethernet chip which requires its own power supply regulators. Add baseboard specific regulators for the SB-T35 Ethernet chip. Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-03-01ARM: dts: sbc-t3x: refactor DT supportDmitry Lifshitz1-0/+11
Refactor the sbc-t3x device tree as a preparation for additional (sbc-t3530, sbc-t3517, etc.) boards support. No functional changes. The device tree will have the following structure: omap3-cm-t3x.dtsi | |<-- omap3-cm-t3x30.dtsi | | | | | | ----- ------- ------------ | | | CoM | | Board | | Base board | | | ----- ------- ------------ | | omap3-sb-t35.dtsi | | | | |<-- omap3-cm-t3730.dts <-- omap3-sbc-t3730.dts -->| | | | | |<-- omap3-cm-t3530.dts <-- omap3-sbc-t3530.dts -->| | | |<-------- omap3-cm-t3517.dts <-- omap3-sbc-t3517.dts -->| Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-19ARM: dts: Add support for sbc-3xxx with cm-t3730Tony Lindgren1-0/+40
This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>