Add support for new compatible st,stm32mp1-rcc-secure used when the
RCC resource is managed by secured world (RCC_TZCR.TZEN=1)
iand when SCMI is used.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add the MISC RCC driver for STM32MP13, and bind it to the RCC reset
driver, required for initial support.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Acked-by: Sean Anderson <seanga2@gmail.com>
Change-Id: Ida11c15462caf140f87b1e3239efa2b8a689acb9
Change debug and pr_err to dev macro and define LOG_CATEGORY.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Update Patrick and my email address with the one dedicated to
upstream activities.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
The RCC driver have no operation so the new NOP uclass
is more appropriate. It only used as parent for clock and reset driver.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Following next kernel rcc bindings, we must use a MFD
RCC driver which is able to bind both clock and reset
drivers.
We can reuse and adapt RCC MFD driver already available
for MCU SoCs (F4/F7/H7).
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Since commit 0e373c0ade ("spl: add SPL_RESET_SUPPORT"),
reset is supported in SPL, enable this flag for STM32F SoCs family.
This allows to remove a specific case in RCC mfd driver.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
On all STM32F4 and F7 SoCs family (except STM32F429), PLLSAI
output P can be used as 48MHz clock source for USB and SDMMC.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Tested By: Bruno Herrera <bruherrera@gmail.com>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
Like STM32H7, now STM32F4/F7 clock drivers are binded by
MFD stm32_rcc driver.
This also allows to add reset support to STM32F4/F7 SoCs family.
As Reset driver is not part of SPL supported drivers, don't bind it
in case of SPL to avoid that stm32_rcc_bind() returns an error.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
This patch adds the support of reset and clock control
block (rcc) found on STM32 SoCs.
This driver is similar to a MFD linux driver.
This driver supports currently STM32H7 only.
STM32F4 and STM32F7 will be migrated to this rcc MFD driver
in the future to uniformize all STM32 SoCs already upstreamed.
Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
