- 16 8月, 2016 15 次提交
-
-
由 Bibek Basu 提交于
Program vdd_core for Jetson TK1 to 1V, which is the max safe voltage for ultra low temperature operations. vdd_cpu and vdd_gpu are already at 1V. Signed-off-by: NBibek Basu <bbasu@nvidia.com> (swarren: fixed comments to better match the code) (swarren: moved board ifdef around data in header, made code generic) (swarren: fixed typos in commit description) Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Bryan Wu 提交于
The L4T kernel complains about a CSITE clock rate above 144MHz, presumably because the HW is only characterized for a clock less than that. Adjust the rate to 136MHz to avoid the warning and stay in spec. Signed-off-by: NBryan Wu <pengw@nvidia.com> (swarren, re-wrote commit description) Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Trimslice currently stores its environment at 512KiB into the SPI flash chip. The U-Boot binary has grown such that the size of the boot image (which includes the Tegra BCT, padding, and the U-Boot binary) is slightly larger than 512K now. Consequently, writing the boot image to flash corrupts the saved environment, and equally, writing to or erasing the environment will corrupt the bootloader, which in turn will cause the Tegra boot ROM to enter recovery mode during boot, making it look as if the system is non-operational. Note that tegra-uboot-flasher writes to the environment during the flashing process. Solve this by moving the environment as high as possible in flash. This will allow the U-Boot binary to roughly double in size before this problem is hit again, at which point there's nothing we can do anyway since the binary won't fit into flash. 99% of other Tegra boards store the environment in eMMC and use a negative value for CONFIG_ENV_OFFSET, which already automatically places the environment as near the end of boot flash as possible. The 1 remaining board hard-codes CONFIG_ENV_OFFSET to 2MiB, which allows for plenty more bloat. Reported-by: NStephen L Arnold <nerdboy@gentoo.org> Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Currently, ft_system_setup() is implemented by board*.c, which are a bit of a dumping ground for a bunch of unrelated functionality, and separate versions exist for pre-Tegra186 and Tegra186. Move the implementation into a separate file to separate functionality, and allow sharing. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
p2771-0000 has a couple of PCIe ports; one physically x4 desktop PCI connector (which may run at x2 electrically, depending on the board version and configuration) and a x1 connection to the M.2 slot (which may not be active, depending on the board version and configuration). This change enables those. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Now that clock and reset drivers exist for Tegra186, we can enable the SD card controller. Now that a BPMP I2C driver exists for Tegra186, we can communicate with the PMIC to enable power to the SD card. Hook up the DT content and board code required to make the SD card work. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Bryan Wu 提交于
Enable I2C devices in DT and enable building tegra_i2c.c driver. Signed-off-by: NBryan Wu <pengw@nvidia.com> (swarren, commit msg rework, fixed DT node sort order) Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Bryan Wu 提交于
clk/reset API was tested on T186 platform and previous chip like T210/T124 will still use the old APIs. Signed-off-by: NBryan Wu <pengw@nvidia.com> (swarren, simplified some ifdefs, removed indent level inside an ifdef) (swarren, added comment about the ifdefs) Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NHeiko Schocher <hs@denx.de> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Tegra186 supports the new standard clock, reset, and power domain APIs. Older Tegra SoCs still use custom APIs. Enhance the Tegra PCIe driver so that it can operate with either set of APIs. On Tegra186, the BPMP handles all aspects of PCIe PHY (UPHY) programming. Consequently, this logic is disabled too. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Tegra186 supports the new standard clock and reset APIs. Older Tegra SoCs still use custom APIs. Enhance the Tegra MMC driver so that it can operate with either set of APIs. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
On Tegra186, some I2C controllers are directly controlled by the main CPU, whereas others are controlled by the BPMP, and can only be accessed by the main CPU via IPC requests to the BPMP. This driver covers the latter case. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NHeiko Schocher <hs@denx.de> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
In Tegra186, SoC power domains are manipulated using IPC requests to the BPMP (Boot and Power Management Processor). This change implements a driver that does that. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
In Tegra186, on-SoC reset signals are manipulated using IPC requests to the BPMP (Boot and Power Management Processor). This change implements a driver that does that. It is unconditionally selected by CONFIG_TEGRA186 since virtually any Tegra186 build of U-Boot will need the feature. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
In Tegra186, on-SoC clocks are manipulated using IPC requests to the BPMP (Boot and Power Management Processor). This change implements a driver that does that. A tegra/ sub-directory is created to follow the existing pattern. It is unconditionally selected by CONFIG_TEGRA186 since virtually any Tegra186 build of U-Boot will need the feature. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
The Tegra BPMP (Boot and Power Management Processor) is a separate auxiliary CPU embedded into Tegra to perform power management work, and controls related features such as clocks, resets, power domains, PMIC I2C bus, etc. This driver provides the core low-level communication path by which feature-specific drivers (such as clock) can make requests to the BPMP. This driver is similar to an MFD driver in the Linux kernel. It is unconditionally selected by CONFIG_TEGRA186 since virtually any Tegra186 build of U-Boot will need the feature. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
- 13 8月, 2016 2 次提交
-
-
-
由 Stephen Warren 提交于
The call op requests that the callee pass a message to the underlying HW or device, wait for a response, and then pass back the response error code and message to the callee. It is useful for drivers that represent some kind of messaging or IPC channel to a remote device. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
- 12 8月, 2016 14 次提交
-
-
由 John Keeping 提交于
Signed-off-by: NJohn Keeping <john@metanate.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 John Keeping 提交于
The voltage and control registers need to be looked up from the value in driver_data. Adjust the get_value and get_enable functions to match the corresponding set_* functions. Signed-off-by: NJohn Keeping <john@metanate.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Stephen Warren 提交于
Some code may want to read reg values from DT, but from nodes that aren't associated with DM devices, so using dev_get_addr_index() isn't appropriate. In this case, fdtdec_get_addr_size_*() are the functions to use. However, "translation" (via the chain of ranges properties in parent nodes) may still be desirable. Add a function parameter to request that, and implement it. Update all call sites to default to the original behaviour. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Squashed in build fix from Stephen: Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Stephen Warren 提交于
The next patch will call fdt_translate_address() from somewhere with a "const void *blob" rather than a "void *blob", so fdt_translate_address() must accept a const pointer too. Constify the minimum number of function parameters to achieve this. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSimon Glass <sjg@chromium.org> Squashed in build fix from Stephen: Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Masahiro Yamada 提交于
Linux stopped the use of keyword 'boolean' in Kconfig. Refer to commit 6341e62b212a2541efb0160c470e90bd226d5496 ("kconfig: use bool instead of boolean for type definition attributes") in Linux Kernel. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Mugunthan V N 提交于
Enable eth driver model for am43xx_evm as cpsw supports driver model. This was already added with the commit bc705ea1 but with commit 4c4e3b37 to add fit support CONFIG_DM_ETH was missed. Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Lokesh Vutla 提交于
cpsw tries to flush dcache which is not in the range of PKTALIGN. Because of this the following warning comes while flushing: CACHE: Misaligned operation at range [dffecec0, dffed016] Fix it by flushing cache of size aligned to PKTALIGN. Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
-
由 Mugunthan V N 提交于
Enable eth driver model for dra7xx_evm as cpsw supports driver model. This was already added with the commit 641b936f but with commit bd724584 to add fit support CONFIG_DM_ETH was missed. Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: NTom Rini <trini@konsulko.com> Acked-by: NLokesh Vutla <lokeshvutla@ti.com>
-
由 Vignesh R 提交于
Enable DM based regulator framework and also fixed regulator support as some IPs like mmc use regulators for there functioning. Signed-off-by: NVignesh R <vigneshr@ti.com> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Vignesh R 提交于
Add a node for evm_3v3_sd using onboard PCF GPIO expander which feeds on to mmc vdd. Update mapping for vmmc-supply and vmmc_aux-supply. evm_3v3_sd supplies to SD card vdd, and ldo1 to sdcard i/o lines. Signed-off-by: NVignesh R <vigneshr@ti.com> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Andreas Dannenberg 提交于
This commit allows injecting a board/platform/device-specific post- processing function into the FIT image data loading process, which can include modifying the size and altering the starting source address of an image data artifact. This might be desired to do things like strip headers or footers attached to the images before they were packaged into the FIT, or to perform operations such as decryption or authentication. Introduce new configuration option CONFIG_FIT_IMAGE_POST_PROCESS to allow controlling this feature. If enabled, a platform-specific post- process function must be provided. Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com> Reviewed-by: NTom Rini <trini@konsulko.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Max Filippov 提交于
Create drivers/sysreset and move sysreset-uclass and all sysreset drivers there. Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Stefan Agner 提交于
Flush operations need to be cacheline aligned to take effect, make sure to flush always complete cachelines. This avoids messages such as: CACHE: Misaligned operation at range [00900000, 009004d9] Signed-off-by: NStefan Agner <stefan.agner@toradex.com> Tested-by: NFabio Estevam <fabio.estevam@nxp.com>
-
由 Simon Glass 提交于
The i2c uclass has a default setting for per_child_platdata_auto_alloc_size so drivers do not need to set it. Remove this from drivers to avoid confusion. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
- 11 8月, 2016 9 次提交
-
-
-
-
由 Masahiro Yamada 提交于
Currently, only the CPU_ON function is supported. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This outer cache allows to control active ways independently for each CPU, so this function will be useful to set up active ways for a specific CPU. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This invalidates entries in specified ways of the outer cache. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
The UniPhier outer cache (L2 cache on ARMv7 SoCs) has 128 byte line length and its tags are also managed per 128 byte line. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Move this option to Kconfig, renaming it into CONFIG_CACHE_UNIPHIER. The new option name makes sense enough, and the same as Linux has. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Now, all of these macros are only used in cache-uniphier.c, so there is no need to export them in a header file. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
The DRAM is available at this point, so setup the temporary stack and call the C function to reduce the code duplication a bit. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-