Skip to content

Reset Controller Driver #43073

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

Merged

Conversation

andrei-edward-popa
Copy link
Contributor

This is my initial work and approach for a generic reset controller driver that can be used in Zephyr. I am open to any ideas for improvement of this driver, but this was my first thought.

@github-actions github-actions bot added area: API Changes to public APIs area: Devicetree area: Devicetree Binding PR modifies or adds a Device Tree binding labels Feb 22, 2022
@carlocaione carlocaione self-requested a review February 22, 2022 15:09
@carlocaione
Copy link
Collaborator

two more points:

@andrei-edward-popa andrei-edward-popa force-pushed the reset_controller branch 2 times, most recently from 49eafe5 to e92b42d Compare February 23, 2022 23:07
@github-actions github-actions bot added the area: Tests Issues related to a particular existing or missing test label Feb 24, 2022
@andrei-edward-popa andrei-edward-popa force-pushed the reset_controller branch 2 times, most recently from ea2fd9e to 6486fd3 Compare February 24, 2022 13:19
Comment on lines 30 to 71
struct reset_dev_config {
/** Reset controller device. */
const struct device *dev;
/** Reset line. */
uint32_t id;
};

/**
* @brief Helper macro to initialize reset controller device config.
*
* @param inst Instance number.
* @param id Reset line.
*/
#define RESET_DEV_CONFIG_INIT(inst, id) \
{ \
.dev = DEVICE_DT_GET(DT_INST_RESET_CTLR(inst)), \
.id = DT_INST_RESET_CELL(inst, id), \
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm a bit puzzled about this. Who is going to use the struct reset_dev_config and how? Take for example

struct mbox_channel {
/** MBOX device pointer. */
const struct device *dev;
/** Channel ID. */
uint32_t id;
};

In this case we have added some helper functions (see the mbox_* functions) that leverage that struct. But in your case how you are supposed to use this struct and why is it there if there is no user?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried to create this struct for getting the reset controller device and its line into some device driver (you can see an example of this in drivers/serial/uart_rpi_pico.c) and if you want to reset the device you can say something like this:
reset_reset(reset->dev, reset->line);
In the line below, 'reset' is a pointer to a reset_dev_config.
I'm not sure how to do it in another way, but if you have any idea I will gladly receive it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

if you want to reset the device you can say something like this:
reset_reset(reset->dev, reset->line);

yes, but that makes sense if you have a wrapper at API level that can unpack that for you, for example reset((struct reset_dev_config *) conf). In your case that wrapper is not being defined at API level so this struct is simply unused (I mean, the same struct can be created by the driver if it is going to be used right?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, yes, I think I understand it, I will try to create some wrappers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@carlocaione I have already a syscall called reset_reset as you saw, and this takes a dev pointer and an id and now I want to create another syscall that takes a reset_dev_config. How can I call it (I'm talking about its name)?

Copy link
Collaborator

Choose a reason for hiding this comment

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

no, do not create more syscalls. All your syscalls are already taking a dev pointer and an id, why don't you simply change the syscalls you have already to take a struct reset_dev_config instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, that's cool.

Copy link
Member

Choose a reason for hiding this comment

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

you should be using device * and not this struct. The reason is that struct device is a kernel object and because of this you can grant or revoke access per thread. You can also go additional validations like if the type of the device is right ...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ceolin What about the MBOX device? It is using a structure like I did. Maybe @carlocaione or @gmarull can clarify this? I'm not sure how to do it in another way and some suggestions would be useful.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@carlescufi
Copy link
Member

@mbolivar-nordic can you please take a look?

@carlescufi carlescufi requested review from erwango and ceolin March 22, 2022 11:09
*
* @param dev Reset controller device.
* @param id Reset line.
* @param status Where to write the reset status.
Copy link
Member

Choose a reason for hiding this comment

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

@andrei-edward-popa what is the format of this "status"? I see there's no enum or bool, just a uint8_t, so it'd be good to document what 'status' means in this context? At least a comment in the PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Status is the current status of the reset, 0 if reset is deasserted and 1 if reset is asserted. This is only 1 bit of the status, the unused 7 bits can be used for other information about the reset or not used at all. Let me know if you think that we need to use bool instead of uint8_t.

Copy link
Member

Choose a reason for hiding this comment

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

No, this sounds good. Thanks for the clarification.

added API and syscalls for reset controller
added reset controller devicetree macro public API header file

Signed-off-by: Andrei-Edward Popa <[email protected]>
added bindings and compatible for reset controller nodes
added bindings for devices that use the reset controller

Signed-off-by: Andrei-Edward Popa <[email protected]>
added bindings for vnd,reset used for devicetree test reset
added adc temp sensor as supporting reset

Signed-off-by: Andrei-Edward Popa <[email protected]>
added test reset for reset public API macros

Signed-off-by: Andrei-Edward Popa <[email protected]>
added needed files for reset controller driver

Signed-off-by: Andrei-Edward Popa <[email protected]>
added documentation for Reset Controller Driver

Signed-off-by: Andrei-Edward Popa <[email protected]>
added reset bindings for Raspberry Pi Pico board

Signed-off-by: Andrei-Edward Popa <[email protected]>
added Reset Controller driver for Raspberry Pi Pico board

Signed-off-by: Andrei-Edward Popa <[email protected]>
added reset controller bindings for Raspberry Pi Pico board

Signed-off-by: Andrei-Edward Popa <[email protected]>
added reset controller node in dtsi
added defines for all reset pins

Signed-off-by: Andrei-Edward Popa <[email protected]>
added resets for Raspberry Pi Pico UART instances
enabled reset controller in defconfig

Signed-off-by: Andrei-Edward Popa <[email protected]>
added reset controller for Raspberry Pi Pico UART devices

Signed-off-by: Andrei-Edward Popa <[email protected]>
@mbolivar-nordic
Copy link
Contributor

Approved and rebased one more time to try to get green CI.

@nashif nashif dismissed stale reviews from mbolivar-nordic, gmarull, and carlocaione via 799bfee March 22, 2022 22:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: Boards area: Devicetree Binding PR modifies or adds a Device Tree binding area: Devicetree area: Documentation area: Tests Issues related to a particular existing or missing test area: UART Universal Asynchronous Receiver-Transmitter platform: Raspberry Pi Pico Raspberry Pi Pico (RPi Pico)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants