- Sep 19, 2018
-
-
When the nand is first probe, and upon the first command start, the status bits should be cleared before the interrupts are unmasked. This commit is taken from Linux: 'commit 0b14392db2e' ("mtd: nand: pxa3xx_nand: fix early spurious interrupt") Signed-off-by:Chris Packham <judge.packham@gmail.com> Signed-off-by:
Ofer Heifetz <oferh@marvell.com> Reviewed-by:
Igal Liberman <igall@marvell.com> Cc: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Signed-off-by:
Stefan Roese <sr@denx.de>
-
Since the pxa3xx_nand driver was added there has been a discrepancy in pxa3xx_nand_set_sdr_timing() around the setting of tWP_min and tRP_min. This brings us into line with the current Linux code. Signed-off-by:
-
Don't store struct mtd_info in struct pxa3xx_nand_host. Instead use the one that is already part of struct nand_chip. This brings us in line with current U-boot and Linux conventions. Signed-off-by:
-
The initial buffer is used for the initial commands used to detect a flash device (STATUS, READID and PARAM). ONFI param page is 256 bytes, and there are three redundant copies to be read. JEDEC param page is 512 bytes, and there are also three redundant copies to be read. Hence this buffer should be at least 512 x 3. This commits rounds the buffer size to 2048. This commit is taken from Linux: 'commit c16340973fcb64614' ("nand: pxa3xx: Increase initial buffer size") Signed-off-by: -
Add support for changing clock rate and parent clock for Armada 37xx peripheral clocks. Only clocks which can be disabled (.can_gate is true) can have parent or rate changed. This is needed so that Turris Mox can change SPI clock in device tree. Signed-off-by:
Marek Behun <marek.behun@nic.cz> Signed-off-by:
-
This adds a weak definition of comphy_update_map to comphy_core, which does nothing. If this function is defined elsewhere, for example in board file, the board file can change some parameters of SERDES configuration. This is needed on Turris Mox, where the SERDES speed on lane 1 has to be set differently when SFP module is connected and when Topaz Switch module is connected. This is a temporary solution. When the comphy driver for armada-3720 will be added to the kernel, the comphy driver in u-boot shall also be updated and this should be done differently then. Signed-off-by:
-
- Sep 15, 2018
-
-
Add vbus-supply regulator support. On some board vbus is not controlled by the phy but by an external regulator. Signed-off-by:Patrice Chotard <patrice.chotard@st.com>
-
Incorrect type of size variable results in 0 being returned for sdram sizes greater than or equal to 4GB. Signed-off-by:Dalon Westergreen <dwesterg@gmail.com>
-
This changes the driver to use dev_read_addr() which is safe both for flat trees and live trees. Signed-off-by:Ley Foon Tan <ley.foon.tan@intel.com>
-
Add code to reset all reset signals as in gpio DT node. A reset property is an optional feature, so only print out a warning and do not fail if a reset property is not present. If a reset property is discovered, then use it to deassert, thus bringing the IP out of reset. Signed-off-by: -
Enabled get_function support for dwapb where the function will return the state of GPIO port. Signed-off-by:
Chin Liang See <chin.liang.see@intel.com> Signed-off-by:
-
- Sep 14, 2018
-
-
Last user of this driver went away in May 2017, in commit eb5ba3ae ("i2c: Drop use of CONFIG_I2C_HARD") Signed-off-by:
Tuomas Tynkkynen <tuomas@tuxera.com>
-
- Sep 12, 2018
-
-
When used with a device tree, this will extract the card detect and write protect pins from the device tree and configure them accordingly. This assumes the GPIO_ACTIVE_LOW/HIGH is supported by da8xx_gpio. Signed-off-by:Adam Ford <aford173@gmail.com>
-
With CONFIG_BLK becoming a requirement, the Davinci MMC driver needs to be updated with DM_MMC support. Since SPL is tiny and many boards do not support DM in SPL, this retains the backwards compatibility for those boards who need to initialize MMC manually in SPL. Signed-off-by:
Peter Howard <phoward@gme.net.au> Signed-off-by:
-
The getcd and getwp functions when DM_MMC is enabled are assumming the DM_GPIO is enabled. In cases (like SPL) where DM_GPIO may not be enabled, wrap these calls in an #ifdef Signed-off-by: -
Platforms with limited resources in SPL may enable OF_PLATDATA, this limits some of the library functions and cannot extract data from the device tree. This patch adds additional wrappers around these functions to only allow them when OF_CONTROL is enabled and OF_PLATDATA is not. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Platforms with limited resources in SPL may enably OF_PLATDATA, this limits some of the library functions and cannot extract data from the device tree. This patch adds additional wrappers around these functions to only allow them when OF_CONTROL is enabled and OF_PLATDATA is not. Signed-off-by: -
Platforms with limited resources in SPL may enably OF_PLATDATA, this limits some of the library functions and cannot extract data from the device tree. This patch adds additional wrappers around these functions to only allow them when OF_CONTROL is enabled and OF_PLATDATA is not. Signed-off-by: -
The driver was developed with references for more than just dra7, but never included. At least for omap3, this appears to be functional. Signed-off-by: -
The GPIO bank numbers do not appear in the device tree, so this patch makes the gpio name based on the address (ie gpio@49054000_31 vs gpio4_31) adam Signed-off-by:
Derald D. Woods <woods.technical@gmail.com>
-
With DM and device tree support, let's use the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW from the device tree as they are intended. Signed-off-by: -
The GPIO banks are broken up into two 16-bit registers for each bank set. Unfortunately, the math that determines how to shift blindly shifted by the number of the gpio. This worked for gpio numbers under 32, but higher gpio's are broken. This fixes the gpio index, so the bank is passed and the shift amount within the register is passed now instead of the gpio number. Fixes: 8e51c0f2("dm: gpio: Add DM compatibility to GPIO driver for Davinci") Signed-off-by:
-
- Sep 11, 2018
-
-
AM654 has an arasan sdhci controller and a mmc phy attached to it. Add basic support for K3 specific arasan sdhci controller. Cc: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by:
Tom Rini <trini@konsulko.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Add an option for building remoteproc drivers within SPL. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Add support for K3 based remoteproc driver that communicates with TISCI to start start a remote processor. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
K3 specific SoCs have a dedicated microcontroller for doing resource management. Any HLOS/firmware on compute clusters should load a firmware to this microcontroller before accessing any resource. Adding support for loading this firmware. After the K3 system controller got loaded with firmware and started up it sends out a boot notification message through the secure proxy facility using the TI SCI protocol. Intercept and receive this message through the rproc start operation which will need to get invoked explicitly after the firmware got loaded. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by:
-
Existing rproc_init() api tries to initialize all available remoteproc devices. This will fail when there is dependency among available remoteprocs. So introduce a separate api that allows to initialize remoteprocs individually based on id. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Add an option for building mailbox drivers within SPL. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Secure Proxy module manages hardware threads that are meant for communication between the processor entities. Adding support for this driver. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: -
Devices from the TI K3 family of SoCs like the AM654x contain a Device Management and Security Controller (SYSFW) that manages the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a system reset driver that communicates to the system controller over the TI SCI protocol for allowing to perform a system- wide SoC reset. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Some TI Keystone 2 and K3 family of SoCs contain a system controller (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and the Device Management and Security Controller on AM65x SoCs) that manage the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a power domain driver that communicates to the system controller over the TI SCI protocol for performing power management of various devices present on the SoC. Various power domain functionalities are achieved by the means of different TI SCI device operations provided by the TI SCI framework. This code is loosely based on the drivers/soc/ti/ti_sci_pm_domains.c driver of the Linux kernel. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
There are cases where there are more than one power domain attached to the device inorder to get the device functional. So add support for enabling power domain based on the index. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Some TI Keystone 2 and K3 family of SoCs contain a system controller (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and the Device Management and Security Controller on AM65x SoCs) that manage the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a clock driver that communicates to the system controller over the TI SCI protocol for performing clock management of various devices present on the SoC. Various clock functionality is achieved by the means of different TI SCI device operations provided by the TI SCI framework. This code is loosely based on the drivers/clk/keystone/sci-clk.c driver of the Linux kernel. Reviewed-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Some TI Keystone 2 and K3 family of SoCs contain a system controller (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and the Device Management and Security Controller on AM65x SoCs) that manage the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a reset driver that communicates to the system controller over the TI SCI protocol for performing reset management of various devices present on the SoC. Various reset functionalities are achieved by the means of different TI SCI device operations provided by the TI SCI framework. This code is loosely based on the drivers/reset/reset-ti-sci.c driver of the Linux kernel. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Add a reset operations function pointer to support querying the current status of a reset control. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
To support scenarios where a firmware device node has subnodes that have their own drivers automatically scan the DT and bind those when the firmware device gets bound. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
TI-SCI message protocol provides support for controlling of various physical cores available in SoC. In order to control which host is capable of controlling a physical processor core, there is a processor access control list that needs to be populated as part of the board configuration data. Introduce support for the set of TI-SCI message protocol apis that provide us with this capability of controlling physical cores. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> -
Since system controller now has control over SoC power management, it needs to be explicitly requested to reboot the SoC. Add support for it. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
-
In general, we expect to function at a device level of abstraction, however, for proper operation of hardware blocks, many clocks directly supplying the hardware block needs to be queried or configured. Introduce support for the set of SCI message protocol support that provide us with this capability. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: -
TI-SCI message protocol provides support for management of various hardware entitites within the SoC. Introduce the fundamental device management capability support to the driver protocol as part of this change. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by:
-
