-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
Reset Controller Driver #43073
Conversation
407953c
to
c075363
Compare
two more points:
|
c075363
to
32e70ba
Compare
49eafe5
to
e92b42d
Compare
e92b42d
to
ff4e278
Compare
ff4e278
to
b98817e
Compare
ea2fd9e
to
6486fd3
Compare
include/drivers/reset.h
Outdated
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), \ | ||
} |
There was a problem hiding this comment.
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
Lines 92 to 98 in 8a8bc39
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that's cool.
There was a problem hiding this comment.
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 ...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ceolin you can still do that, see https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/mbox/mbox_handlers.c
6486fd3
to
d53b5c5
Compare
@mbolivar-nordic can you please take a look? |
* | ||
* @param dev Reset controller device. | ||
* @param id Reset line. | ||
* @param status Where to write the reset status. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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]>
7eeb57f
to
799bfee
Compare
Approved and rebased one more time to try to get green CI. |
799bfee
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.