- 13 Sep, 2016 8 commits
-
-
Tony Lindgren authored
Some omap5 variants have more than 2GB of memory available as optional models. Let's update the dts files to use two address cells similar to what dra7 is using with commit dae320ec ("ARM: dts: DRA7: change address-cells and size-cells"). Acked-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Nishanth Menon authored
Latest update to the BeagleBoard-X15 platform (revision B1)[1] updates for allowing UHS SD cards to function with the split of supply to SD card from a dedicated LDO. As a result of this, AM57xx BeagleBoard-X15 now uses gpio2_30 instead of gpio6_28 for HDMI because HDMI_LS_OE should now be switched from GPIO6_28(Y9) to GPIO2_30 (AG8) to avoid a 1.8V GPIO toggling a 3.3V SoC input when the SD card is in UHS 1.8V mode. NOTE: For UHS mode to function, we need full fledged IODelay support in kernel to be functional. IODelay support is yet to be added. Further, It does not make much sense to spin off a new board compatible flag since there is no real functional benefit for the same. Note: Even though production version is supposed to be B1, there is over ~200 boards of previous version (A2)[2] out there which continue to get supported with the existing dts file (to maintain compatibility with existing bootloaders for A2) and the production board is now supported as revb1. [1] https://github.com/beagleboard/beagleboard-x15/blob/master/BEAGLEBOARD_X15_REV_B1.pdf [2] http://marc.info/?l=linux-arm-kernel&m=147273929820708&w=2Tested-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Nishanth Menon authored
Pinmuxing for DRA7x/AM57x family of processors need to be done in IO isolation as part of initial bootloader executed from SRAM. This is done as part of iodelay configuration sequence and is required due to the limitations introduced by erratum ID: i869[1] (IO Glitches can occur when changing IO settings) and elaborated in the Technical Reference Manual[2] 18.4.6.1.7 Isolation Requirements. Only peripheral that is permitted for dynamic pin mux configuration is MMC and DCAN. MMC is permitted to change to accommodate the requirements for varied speeds (which require IO-delay support in kernel as well). DCAN is a result of i893[1] (DCAN initialization sequence). However, since we don't use DCAN on X15, with the exception of MMC, all other pin mux configurations are removed from the dts. [1] http://www.ti.com/lit/pdf/sprz429 [2] http://www.ti.com/lit/pdf/sprui30Signed-off-by:
-
Tony Lindgren authored
The LEDs on igepv5 are on the GPIO expander unlike on omap5-uevm. Configuration copied from git.isee.biz git tree except fixed for red and blue mapping. Signed-off-by: -
Tony Lindgren authored
Add power button support for igepv5. Cc: Agustí Fontquerni i Gorchs <afontquerni@iseebcn.com> Cc: Enric Balletbo Serra <eballetbo@gmail.com> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Cc: Pau Pajuel <ppajuel@gmail.com> Signed-off-by: -
Tony Lindgren authored
The ID pin GPIO comes from the PMIC. Let's configure it as a GPIO for the driver to use, and also make sure the PMIC GPIO pin muxing is correct. The PMIC pad1 and 2 values for omap5-uevm and igepv5 are 0x5a and 0x1b, we only need to clear bit 2 in pad1 register to make the ID pin GPIO work. Signed-off-by: -
Tony Lindgren authored
Few changes to fix issues I've noticed while debugging omap5-uevm wl18xx issues: 1. Move wlcore irq pin muxing under wlcore. This irq could be different from gpio_wk14 on some board variants 2. Don't configure pull on wlcore irq pin. There is a 10k pull up resistor R105 on the device to VDDS_1v8_MAIN 3. The padconf register for wlsdio_data1 is wrong, it's really at 0x1a8 + 2 - 0x40 = 0x16a offset, not at 0x168 as that's for wlsdio_data0 4. Mark the omap5-uevm wlan as compatible with ti,wl1837 as that's what the TDK R078 part seems to be 5. The MMC interrupt for WLAN musb be wakeupgen, not gic Looks like omap5-uevm WLAN behaves better now, but I still seem to have issues with some access points. Signed-off-by: -
Tony Lindgren authored
Otherwise we have delays on noticing interrupts from the WLAN card when idle. Signed-off-by:
-
- 31 Aug, 2016 25 commits
-
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by:
-
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it shouldn't have functional changes. Since no am4372 based board had a memory node defined, a dummy node is added so the compiled DTB memory node is the same than before. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same besides an empty chosen node being removed and nodes reordered, so it should not have functional changes. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" But these boards don't have a memory node defined, so removing the skeleton.dtsi inclusion from omap3.dtsi will cause a change in the compiled DTB. Add a dummy memory node so the compiled DTB doesn't change if the skeleton.dtsi is removed from omap3.dtsi. Eventually the correct starting addresses and sizes should be used but I didn't find that information. Signed-off-by: -
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" But the sl50 board doesn't have a, so removing the skeleton.dtsi inclusion from am33xx.dtsi will cause a change in the compiled DTB. The board has 512 MiB of RAM and its starting address is 0x80000000, so add a proper memory device node in the DTS. Signed-off-by: -
Grygorii Strashko authored
Current clocks tree definition for CPSW/CPTS doesn't correspond TRM for dra7/am57 SoCs. CPTS: has to be sourced from gmac_rft_clk_mux clock CPSW: DPLL_GMAC -> CLKOUT_M2 -> GMAC_250M_CLK -> 1/2 -> -> GMAC_MAIN_CLK (125 MHZ) Hence, correct clock tree for GMAC_MAIN_CLK and use proper clock for CPTS. This also require updating of CPTS clock multiplier. Signed-off-by:Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by:
Mugunthan V N <mugunthanvnm@ti.com> Acked-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
J.D. Schroeder authored
This commit fixes the clock data inside the DRA7xx clocks device tree structure for the gmac_gmii_ref_clk_div clock. This clock is actually the GMAC_MAIN_CLK and has nothing to do with the register at address 0x4a0093d0. If CLKSEL_REF bit 24 inside of CM_GMAC_GMAC_CLKCTRL, is set to 1 in order to use the GMAC_RMII_CLK instead of the GMAC_RMII_HS_CLK, the kernel generates a clock divider warning: WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:129 clk_divider_recalc_rate+0xa8/0xe0() gmac_gmii_ref_clk_div: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set By properly configuring the gmac_gmii_ref_clk_div (GMAC_MAIN_CLK) to have the parent of dpll_gmac_m2_ck always divided by 2 the warning is resolved and the clock tree is fixed up. Additionally, a new clock called rmii_50mhz_clk_mux is defined that does utilize CM_GMAC_GMAC_CLKCTRL[24] CLKSEL_REF to configure the source clock for the RMII_50MHZ_CLK. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:J.D. Schroeder <jay.schroeder@garmin.com> Reviewed-by:
Trenton Andres <trenton.andres@garmin.com> Signed-off-by:
-
- 30 Aug, 2016 2 commits
-
-
Kishon Vijay Abraham I authored
Since DRA7 has multiple PCIe Rootcomplex, add "linux,pci-domain" property to assign a PCI domain number to each of the host bridges. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Vignesh R authored
AM335x ICE board has a rotary-switch connected to PCA9536 I2C GPIO expander. The position of the rotary-switch is reflected by status of GPIO lines. Add gpio-decoder node to read these GPIO line status via gpio-decoder driver and report it as an input event to the system. Signed-off-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
-
- 29 Aug, 2016 1 commit
-
-
Adam Ford authored
Support is in the device tree, but they are not mentioned here. Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
-
- 26 Aug, 2016 4 commits
-
-
Sekhar Nori authored
Silicon limitation i845 documents how to cope with false disconnection condition on USB2 PHY. Reference: AM572x silicon errata document SPRZ429H, revised January 2016. Using compatible "ti,dra7x-usb2" enables the recommended software workaround for this issue. Use it for USB1 PHY. The workaround is already in place for USB2 PHY. Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Stefan Müller-Klieser authored
The wega board has a TLV320AIC3007 connected via McASP0. In the default configuration, no external crystal is mounted. We run a system clock of 25 MHz, so we use the audio codec PLL for audio clock generation. Signed-off-by:
Stefan Müller-Klieser <s.mueller-klieser@phytec.de> Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Vignesh R authored
AM572x IDK has a Spansion s25fl256s1 QSPI flash on the EVM connected to TI QSPI IP over CS0. Hence, add QSPI and flash slave DT nodes. Signed-off-by:
-
Vignesh R authored
According to AM572x DM SPRS953A, QSPI maximum bus speed can be 76.8MHz. Therefore, increase the spi-max-frequency value of QSPI node to 76.8MHz for DRA74 and DRA72 evm. This improves flash raw read speed by ~2MB/s. Signed-off-by:
-
