- 28 Apr, 2016 4 commits
-
-
Keerthy authored
am57xx-idk have Industrial grade samples whose thermal thresholds are different as compared with dra7. Hence correcting the same. Signed-off-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Keerthy authored
am57xx-beagle-x15 have commercial grade samples whose thermal thresholds lower than dra7. Hence correcting the same. Signed-off-by:
-
Keerthy authored
The silicon version ES2.0 onwards are industrial grade samples and have higher thermal thresholds than commecial grade samples. Signed-off-by:
-
Keerthy authored
The silicon versions which are non ES2.0 are commercial grade silicon and have lower thermal thresholds. Signed-off-by:
-
- 26 Apr, 2016 12 commits
-
-
Yegor Yefremov authored
Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
-
Yegor Yefremov authored
Signed-off-by:
-
Yegor Yefremov authored
Introduce am335x-baltos.dtsi, that provides common configuration for the whole device family based on the same SODIMM module. Signed-off-by:
-
Vignesh R authored
According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on DRA74(rev 1.1+)/DRA72 EVM can support up to 64MHz in MODE-0, whereas MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better throughput. Signed-off-by:
Vignesh R <vigneshr@ti.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Vignesh R authored
DRA7 family of processors from Texas Instruments, have a hardware module called IODELAYCONFIG Module which is expected to be configured. This block allows very specific custom fine tuning for electrical characteristics of IO pins that are necessary for functionality and device lifetime requirements. IODelay module has it's own register space with registers to configure various pins. According to AM572x TRM SPRUHZ6E October 2014–Revised January 2016[1] section 18.4.6.1 Pad Configuration, in addition to pinmuxing(MUXMODE), when operating a pad in certain mode, Virtual/Manual IO Timing Mode must also be configured to ensure that IO timings are met (DELAYMODE and MODESELECT fields of pad's IODELAYCONFIG module register). According to section 18.4.6.1.7 Isolation Requirements of above TRM, when reprogramming MUXMODE, DELAYMODE, and MODESELECT fields, there is a potential for a significant glitch on the corresponding IO. It is hence recommended to do this with I/O isolation (which can only be done in initial stages of bootloader). QSPI is one such module that requires IODELAY configuration. So, this patch removes the pinmux for QSPI for DRA74/DRA72 EVM as it needs to be done in bootloader (U-Boot) and cannot be done in kernel. Users should migrate to U-Boot v2016.05-rc1 or higher. [1] http://www.ti.com/lit/ug/spruhz6e/spruhz6e.pdfSigned-off-by:
-
H. Nikolaus Schaller authored
tested on OMP5432 EVM Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by:
-
H. Nikolaus Schaller authored
tested on Pandaboard ES. Signed-off-by:
-
Roger Quadros authored
The boards use a TI variant of the PCF8575 so specify that in the compatible string. Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Nishanth Menon authored
As per the data sheet starting from SPRUHQ0H (Nov 2015 - Latest[1]), VDD_CORE can vary from 0.85v to 1.15v for AVS class0. VDD GPU/DSP et.al. can range from 0.85v to 1.25V with AVS class0 Since dynamic voltage scaling is disabled for DRA7/AM57xx SoCs for all SoC rails other than MPU, the bootloader is responsible for setting up the AVS class0 voltage, however, with wrong voltage machine constraints in dtb, regulator framework will lower the voltage below the required voltage levels for certain samples in production flow. This can cause catastrophic failures which can be pretty hard to identify. Update board files which don't match required specification. [1] http://www.ti.com/product/AM5728/datasheet/specifications#SPRT637-7340Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
- 14 Apr, 2016 4 commits
-
-
Nishanth Menon authored
DRA72-EVM now has an upgrade to Rev C with SR2.0 silicon. As part of this change, a few updates were factored in that were software incompatible with previous board in few areas: - We now use DP83867 ethernet phy instead of older DP838865 which fails in certain use cases. - Two Ethernet ports now instead of the single one in rev B. - polarities changed for certain pcf gpios - Due to SoC phy current requirements, VDDA supplies are split between ldo3 and ldo2 (ldo2 was previously unused). NOTE: DSS (VDDA_VIDEO) is still supplied by ldo5, HDMI is now supplied by LDO2 instead of using LDO3. NOTE: It does not make much sense to spin off a new board compatible flag since there is no real benefit for the same. Signed-off-by:
-
Marcin Niestroj authored
ChiliSOM has TPS65217's PWR_EN pin connected to AM335x PMIC_POWER_EN pin. Processor's PMIC_POWER_EN is controlled by it's internal RTC, hence RTC subsystem is responsible for proper board poweroff sequence. This change enables complete poweroff sequence for ChiliBoard, switching PMIC's state from ACTIVE to SLEEP. Signed-off-by:
Marcin Niestroj <m.niestroj@grinn-global.com> Signed-off-by:
-
Marcin Niestroj authored
ChiliSOM has 2 Ethernet subsystems with different types of possibly used PHY interfaces (i.e. MII, RMII, GMII, RGMII). Current code configured pinmux for RMII on 1st Ethernet subsystem and enabled Ethernet MAC with 1 slave for all boards which use ChiliSOM. This change moves pinmux configuration of 1st Ethernet subsystem to ChiliBoard description, as this is board-specific. Signed-off-by:
-
Marcin Niestroj authored
uart0 configuration code has been in SOM. However, it is possible to use all (or none) of 6 uart's of AM335x processor present on ChiliSOM. This fix moves declaration of uart0 from ChiliSOM to ChiliBoard, because use of uart is strictly board-specific. Signed-off-by:
-
- 13 Apr, 2016 1 commit
-
-
Tero Kristo authored
clkout1 clock node and its generation tree was missing. Add this based on the data on TRM and PRCM functional spec. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Tested-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
- 12 Apr, 2016 19 commits
-
-
Roger Quadros authored
On these boards NAND ready pin status is avilable over GPMC_WAIT0 pin. For NAND we don't use GPMC wait pin monitoring but get the NAND Ready/Busy# status using GPIOlib. GPMC driver provides the WAIT0 pin status over GPIOlib. Read speed increases from 13212 KiB/ to 15753 KiB/s and write speed was unchanged at 4404 KiB/s. Measured using mtd_speedtest.ko on omap3-beagle-c4. Signed-off-by:
-
Roger Quadros authored
On these boards NAND ready pin status is avilable over GPMC_WAIT0 pin. For NAND we don't use GPMC wait pin monitoring but get the NAND Ready/Busy# status using GPIOlib. GPMC driver provides the WAIT0 pin status over GPIOlib. Read speed increases from 7869 KiB/ to 8875 KiB/s and write speed was unchanged at 5100 KiB/s. Measured using mtd_speedtest.ko on am335x-evm. Cc: Teresa Remmet <t.remmet@phytec.de> Cc: Ilya Ledvich <ilya@compulab.co.il> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Rostislav Lisovy <lisovy@gmail.com> Cc: Enric Balletbo i Serra <eballetbo@iseebcn.com> Signed-off-by:
-
Roger Quadros authored
On these boards NAND ready pin status is avilable over GPMC_WAIT0 pin. For NAND we don't use GPMC wait pin monitoring but get the NAND Ready/Busy# status using GPIOlib. GPMC driver provides the WAIT0 pin status over GPIOlib. Read speed increases from 16516 KiB/ to 18813 KiB/s and write speed was unchanged at 9941 KiB/s. Measured using mtd_speedtest.ko. Signed-off-by:
-
Roger Quadros authored
On these boards NAND ready pin status is avilable over GPMC_WAIT0 pin. Read speed increases from 13768 KiB/ to 17246 KiB/s. Write speed was unchanged at 7123 KiB/s. Measured using mtd_speedtest.ko. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides GPI support for the GPMC_WAIT pins. Mark it gpio controller capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides GPI support for the GPMC_WAIT pins. Mark it gpio controller capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides GPI support for the GPMC_WAIT pins. Mark it gpio controller capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides GPI support for the GPMC_WAIT pins. Mark it gpio controller capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides GPI support for the GPMC_WAIT pins. Mark it gpio controller capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides GPI support for the GPMC_WAIT pins. Mark it gpio controller capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides interrupts and gpio for the GPMC_WAIT pins. Mark it as gpio and interrupt capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides interrupts and gpio for the GPMC_WAIT pins. Mark it as gpio and interrupt capable. Signed-off-by:
-
Roger Quadros authored
GPMC driver provides interrupts and gpio for the GPMC_WAIT pins. Mark it as gpio and interrupt capable. Signed-off-by:
-
Paul Kocialkowski authored
This adds support for turning off the main power supply via the TWL6030 on the Kindle Fire (first generation). Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
-
Paul Kocialkowski authored
This adds support for the Kindle Fire (first generation) power button LEDs, that are wired to the TWL6030 PWM outputs. Signed-off-by:
-
Paul Kocialkowski authored
This adds support for USB OTG on the Kindle Fire (first generation). Signed-off-by:
-
Paul Kocialkowski authored
The Amazon Kindle Fire (first generation) codename kc1 is a tablet that was released by Amazon back in 2011. It is using an OMAP4430 SoC GP version. This adds devicetree support for the device, with only a few basic features supported, such as debug uart, i2c and internal emmc. Signed-off-by:
-
Paul Kocialkowski authored
This adds the amazon vendor prefix for Amazon.com, Inc. Signed-off-by:
-
Yegor Yefremov authored
Before "tty: Add software emulated RS485 support for 8250" patch Baltos devices relied on MCTRL_GPIO framework to handle both modem signals and RS485 mode. With emulated RS485 support for 8250 we can now use these pins as dedicated RTS/CTS signals taking advantage of hardware flow control etc. when operating in RS232 mode. Signed-off-by:
-
