Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

boards: arm: Add Renesas Spider board #56043

Merged
merged 8 commits into from
Nov 25, 2023

Conversation

aaillet
Copy link
Member

@aaillet aaillet commented Mar 21, 2023

This pull request is introducing Generation 4 of Renesas R-Car SoCs with the S4 SoC as well as the Spider board into Zephyr.

Gen4 SoCs vs Gen3 (Zephyr POV) :

Cortex-R52 is now used as Real Time core
We are now able to use embedded ARM timer
Some IPs are the same and will use existing drivers, sometime with few improvements (UART, GPIO...)
Introduction of new IPs
S4 SoC that is equipping multiple Gen4 boards have some Cortex-A55s and a Cortex-R52 core.

Spider board is the reference board for S4 SoC, developpment oriented, this board is providing a lot of available IOs.

Operation of basic samples such as hello_world and blinky have been validated.

@aaillet
Copy link
Member Author

aaillet commented Mar 27, 2023

This PR is ready to be reviewed as the last CI failure is a false positive !
pinctrl_soc_pin_t type has to be defined as documented here : https://docs.zephyrproject.org/latest/hardware/pinctrl/index.html#pin-control-drivers.

@MaureenHelm
Copy link
Member

@gmarull @povergoing can you take a look please?

povergoing
povergoing previously approved these changes Apr 11, 2023
Copy link
Member

@povergoing povergoing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for the R52 part

clocks = <&cpg CPG_MOD 702>, <&cpg CPG_CORE R8A779F0_CLK_S0D12_PER>;
};

/* Linux console */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just out of curiosity, Why there is a Linux console?

Copy link
Member Author

@aaillet aaillet Apr 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your review !
On this SoC, Linux is running on A55s cores while Zephyr is running on the R52 !
Devices like serial lines are common for both "worlds".
I added both "physically accessible" serial lines to the device tree as users could have different use cases than running Linux and Zephyr at the same time.
I commented this serial line as "Linux console" for users to know that this one is already used in a Linux+Zephyr use case !

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, Cortex A cluster uses HSCIF0 nowadays.

Comment on lines 106 to 118
const struct pfc_bias_reg *pfc_rcar_get_bias_regs(void);
const struct pfc_drive_reg *pfc_rcar_get_drive_regs(void);

/**
* @brief set the register index for a given pin
*
* @param the pin
* @param pointer for the resulting register index
* @return 0 if the register index is found, negative
* errno otherwise.
*/
int pfc_rcar_get_reg_index(uint8_t pin, uint8_t *reg_index);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be part of pinctrl_soc, as it's something needed internally by drivers. please, create a new internal header so that drivers/pinctrl.h is not polluted with unnecessary stuff.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @gmarull ,
Thanks for your comment.
If my understanding is fine, you want me to move these common declaration to a new file here zephyr/include/zephyr/drivers/pinctrl/pinctrl_rcar_common.h ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @gmarull, I'm currently reworking this PR to merge some changes with #60252 , can you confirm that I understood well your remark before I proceed ? Thanks

Copy link
Member

@gmarull gmarull Aug 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean is that this should only be exposed to code requiring it. An internal header is fine, but decoupled from pinctrl_soc.h (which ends up included in pinctrl.h)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it, please tel me if it's ok now !

@github-actions
Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the Stale label Jun 26, 2023
@aaillet aaillet removed the Stale label Jun 26, 2023
Copy link
Member

@henrikbrixandersen henrikbrixandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GPIO changes okay.

Copy link
Collaborator

@lorc lorc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a small comment regarding SCIF3/HSCIF0 used by Cortex A cluster. If I remember correctly, Renesas BSP moved Cortex A to HSCIF0. At least this is what we use in OP-TEE, U-Boot and Xen.

clocks = <&cpg CPG_MOD 702>, <&cpg CPG_CORE R8A779F0_CLK_S0D12_PER>;
};

/* Linux console */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, Cortex A cluster uses HSCIF0 nowadays.

@aaillet
Copy link
Member Author

aaillet commented Nov 22, 2023

I have a small comment regarding SCIF3/HSCIF0 used by Cortex A cluster. If I remember correctly, Renesas BSP moved Cortex A to HSCIF0. At least this is what we use in OP-TEE, U-Boot and Xen.

I think that we agree on this subject.

Physically SCIF3 and HSCIF0 are using the same lines and Cortex A's are using HSCIF0. (HSCIF1 and SCIF0 are on the same line as well)
Zephyr part is only supporting SCIF so I listed physically available lines in the device tree.
As typical use case is that Cortex A's are using HSCIF0, I selected SCIF0 as main Zephyr serial port.

For other use cases, Zephyr may use SCIF3 line.

Please keep in mind that HSCIF0 and SCIF0 are not on the same line, they can work at the same without any issues. (On different physical port)

I hope I answered your comments.

lorc
lorc previously approved these changes Nov 22, 2023
Copy link
Collaborator

@lorc lorc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thank you.

Overview
********

R-Car S4 enables the launch of Car Server/CoGW with high performance, high-speed networking, high security and high functional safety levels that are required as E/E architectures evolve into domains and zones.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you wrap the lines to either 80 or 100 columns? sorry we don't have a check for this yet but that's how these docs are normally done

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, but how should I manage links that are longer than 100 characters then ?
They are gathered at the bottom of the rst file

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those are fine, just wrap the normal text

int ret = -ENOTSUP;
uint32_t reg;

enable = !!enable;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does not look like this is used, stale? guess you may want to remove the argument entirely

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not used yet as current driver don't need their clocks to be enabled or disabled manually.
This whole function is a placeholder to keep skeleton from other renesas clock driver.
It's also already planned that the arm64 support of this soc (coming just after this PR, see #60252 ) will need some clocks to be enable/disabled for some drivers.

More specifically, this argument is just as a boolean to know if this function is called to enable or disable the concerned clock.

That's all reasons why this function has to be here but is not used yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, keep the argument, drop this line? or mark it as ARG_UNUSED

struct cpg_clk_info_table *clk_info;
struct r8a779f0_cpg_mssr_data *data = dev->data;
k_spinlock_key_t key;
int ret = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

drop the initializer, return with return 0; at the end of the function

clock_control_subsys_t sys, bool enable)
{
struct rcar_cpg_clk *clk = (struct rcar_cpg_clk *)sys;
int ret = -EINVAL;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need to initialize this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was getting "may be used uninitialized" warning when declaring ret uninitialized

adding an "else" initializing ret at -EINVAL to fix warning


static uint32_t r8a779f0_get_div_helper(uint32_t reg_val, uint32_t module)
{
uint32_t divider = RCAR_CPG_NONE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about using explicit return and ditching the variable? easier to follow...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not !


static int r8a779f0_set_rate_helper(uint32_t module, uint32_t *divider, uint32_t *div_mask)
{
int ret = -ENOTSUP;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just return -ENOSUP for now, you can add stuff later with the structure that makes sense at that point

@aaillet
Copy link
Member Author

aaillet commented Nov 23, 2023

Addressed comments from @fabiobaltieri concerning board documentation and clock driver.

}

int r8a779f0_cpg_mssr_start_stop(const struct device *dev,
clock_control_subsys_t sys, bool enable)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry one more indentation nitpick: under the previous parenthesis is how it's normally done here, you are mixing thigs up a bit in the file, here you are just doing a tab, in r8a779f0_cpg_mssr_start you are back one charcter, could you check these and make sure they are at least coherent within the file?

int r8a779f0_cpg_mssr_start_stop(const struct device *dev,
                                 clock_control_subsys_t sys, bool enable)
static int r8a779f0_cpg_mssr_start(const struct device *dev,
                                   clock_control_subsys_t sys)

is how it should be

Copy link
Member Author

@aaillet aaillet Nov 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

running clang-format on the entire file as it is a new one could be the right call ?

Copy link
Member

@fabiobaltieri fabiobaltieri Nov 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang-format mostly works but often does a bit of a disaster on complex macros, if you want to use it fine but don't take the output religiously, either commit locally, clang-format and then manually git checkout -p the messy chunks, or add some /* clang-format off */ /* clang-format on */ markers around the part it messes up, if any.

if (!ret) {
rcar_cpg_write(DEVICE_MMIO_GET(dev), clk_info->offset, reg);
}
return ret;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would not you be better off just return -ENOTUP and then implement the whole thing once there's something to do? I understand you want to have the stubs but it just looks really really weird right now, plus the way you are using ret around is hard to follow and does not look quite right

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just need to check if it is mandatory to write clk reg when errors are happening (l67) in the controller doc.
If it is, I'll just do this rcar_cpg_write before returning ENOTSUP 👍

Yeah, I totally understand that these placeholders are weird right now, at least keeping them with a return -ENOTSUP is already nice for the driver creation !

xakep-amatop and others added 5 commits November 24, 2023 12:38
Add support of r8a779f0 cpg driver.
r8a779f0 soc has its own clock tree.
Gen4 SoCs common registers addresses have been added in header.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
r8a779f0 is also know as S4, this SoC is part of the Gen4 SoC series,
has 8 Cortex-A55 and a dual core lockstep Cortex-R52 processor.

SCIF0 is dedicated to Zephyr and SCIF3 to Linux.

**Control Domains**
IMPORTANT: This SoC is divided into two "domains":
- Application domain contains some peripherals as well as A55 & R52 cores.
- Control domain that contain a G4MH/RH850 MCU and other peripherals.

In order to access control domain peripherals such as gpio4-7 and CAN-FD
from application domain, the G4MH MCU has to unlock a protection
mechanism from control domain buses.

"Protected" controllers will be flagged in gen4 device trees,
warning users that they need to flash a custom G4MH firmware
to unlock access to these controllers.

**Clock controller**
This SoC clock controller is offering "domains"
for each world (Zephyr/Linux).

These domains are several "entry points" to the clock controller
which are arbitrated to avoid a world from turning off a clock needed
by another one.

We decided to use the same domain as Linux because the
security mechanism as to be implemented before accessing
another domain.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
r8a779f0 SoC is part of the Renesas R-Car Gen4 SoC series.

This SoC has a dual core lockstep Cortex-R52 CPU.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
Renesas Spider board use a S4 SoC (r8a779f0).

Add basic support for UART, GPIO and clock control.

We are using SCIF0 as SCIF3 is used by Linux.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
Adding Spider board documentation based on Renesas official documentation
and following Zephyr guideline.

The documentation is describing the board and its current
Zephyr support.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
@aaillet
Copy link
Member Author

aaillet commented Nov 24, 2023

Addressed last comments from @fabiobaltieri concerning clock driver

@nashif nashif merged commit 36f2627 into zephyrproject-rtos:main Nov 25, 2023
19 checks passed
aaillet added a commit to iotbzh/zephyr that referenced this pull request Nov 29, 2023
Based on edit done at r8a779f0 driver creation (f5634a1)
following comments on zephyrproject-rtos#56043.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
aaillet added a commit to iotbzh/zephyr that referenced this pull request Nov 29, 2023
Based on edit done at r8a779f0 driver creation (f5634a1)
following comments on zephyrproject-rtos#56043.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
@aaillet aaillet deleted the for-upstream/add-spider branch November 29, 2023 14:51
aaillet added a commit to iotbzh/zephyr that referenced this pull request Nov 29, 2023
Based on edit done at r8a779f0 driver creation
(f5634a1)
following comments on zephyrproject-rtos#56043.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
carlescufi pushed a commit that referenced this pull request Jan 29, 2024
Based on edit done at r8a779f0 driver creation
(f5634a1)
following comments on #56043.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
pdgendt pushed a commit to pdgendt/zephyr that referenced this pull request Jan 30, 2024
Based on edit done at r8a779f0 driver creation
(f5634a1)
following comments on zephyrproject-rtos#56043.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
piotrnarajowski pushed a commit to piotrnarajowski/zephyr that referenced this pull request Jan 31, 2024
Based on edit done at r8a779f0 driver creation
(f5634a1)
following comments on zephyrproject-rtos#56043.

Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ARM64 ARM (64-bit) Architecture area: Clock Control area: Devicetree Binding PR modifies or adds a Device Tree binding area: GPIO area: Pinctrl platform: Renesas R-Car ARM64 Renesas Electronics Corporation, R-Car ARM64 platform: Renesas R-Car Renesas R-Car
Projects
None yet
Development

Successfully merging this pull request may close these issues.