| Message ID | 1424455277-29983-6-git-send-email-mcoquelin.stm32@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Friday 20 February 2015 19:01:04 Maxime Coquelin wrote: > Some platforms need to initialize the reset controller before the timers. > > This patch introduces a reset_controller_of_init() function that can be > called before the timers intialization. > > Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> > Not sure about this. It seems like the cleanest approach if we get a lot of these, but then again it is probably very rare, and I'd like to avoid adding such infrastructure if it's just for one SoC. Could we add a hack in the machine initialization instead? I think ideally this would be done in the boot loader before we even start Linux, but I don't know if that's possible for you. Arnd
2015-03-10 16:00 GMT+01:00 Arnd Bergmann <arnd@arndb.de>: > On Friday 20 February 2015 19:01:04 Maxime Coquelin wrote: >> Some platforms need to initialize the reset controller before the timers. >> >> This patch introduces a reset_controller_of_init() function that can be >> called before the timers intialization. >> >> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> >> > > Not sure about this. It seems like the cleanest approach if we get > a lot of these, but then again it is probably very rare, and I'd > like to avoid adding such infrastructure if it's just for one > SoC. Could we add a hack in the machine initialization instead? Sun6i also need to initialize the reset controller early. Today, they hack the machine initialization. With two SoCs having the same need, what should we do? That said, I'm fine with either way. If reset_controller_of_init gets accepted, I will send the patch for sun6i. > > I think ideally this would be done in the boot loader before we > even start Linux, but I don't know if that's possible for you. From what I understand, the only constraint is to perform it after the clock is enabled. So this should be possible to do it in the bootloader, but it means also adding timers clocks ungating in the bootloader. Br, Maxime > > Arnd
On Tuesday 10 March 2015 16:28:44 Maxime Coquelin wrote: > 2015-03-10 16:00 GMT+01:00 Arnd Bergmann <arnd@arndb.de>: > > On Friday 20 February 2015 19:01:04 Maxime Coquelin wrote: > >> Some platforms need to initialize the reset controller before the timers. > >> > >> This patch introduces a reset_controller_of_init() function that can be > >> called before the timers intialization. > >> > >> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> > >> > > > > Not sure about this. It seems like the cleanest approach if we get > > a lot of these, but then again it is probably very rare, and I'd > > like to avoid adding such infrastructure if it's just for one > > SoC. Could we add a hack in the machine initialization instead? > > Sun6i also need to initialize the reset controller early. Today, they > hack the machine initialization. > With two SoCs having the same need, what should we do? Good question, I'd like to hear some other opinions on this first. > > I think ideally this would be done in the boot loader before we > > even start Linux, but I don't know if that's possible for you. > > From what I understand, the only constraint is to perform it after the > clock is enabled. > So this should be possible to do it in the bootloader, but it means > also adding timers clocks ungating in the bootloader. Ungating the timer clock input seems like a reasonable thing to do for the bootloader, I think a lot of platforms rely on this elsewhere (but enough of them don't, which is why we have the early clk init). Arnd
On Tue, Mar 10, 2015 at 3:19 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 10 March 2015 16:28:44 Maxime Coquelin wrote: >> 2015-03-10 16:00 GMT+01:00 Arnd Bergmann <arnd@arndb.de>: >> > On Friday 20 February 2015 19:01:04 Maxime Coquelin wrote: >> >> Some platforms need to initialize the reset controller before the timers. >> >> >> >> This patch introduces a reset_controller_of_init() function that can be >> >> called before the timers intialization. >> >> >> >> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> >> >> >> > >> > Not sure about this. It seems like the cleanest approach if we get >> > a lot of these, but then again it is probably very rare, and I'd >> > like to avoid adding such infrastructure if it's just for one >> > SoC. Could we add a hack in the machine initialization instead? >> >> Sun6i also need to initialize the reset controller early. Today, they >> hack the machine initialization. >> With two SoCs having the same need, what should we do? > > Good question, I'd like to hear some other opinions on this first. 2 is still far from the common case. >> > I think ideally this would be done in the boot loader before we >> > even start Linux, but I don't know if that's possible for you. >> >> From what I understand, the only constraint is to perform it after the >> clock is enabled. >> So this should be possible to do it in the bootloader, but it means >> also adding timers clocks ungating in the bootloader. > > Ungating the timer clock input seems like a reasonable thing to > do for the bootloader, I think a lot of platforms rely on this > elsewhere (but enough of them don't, which is why we have the > early clk init). +1 If the bootloader is u-boot, then you need a timer anyway. Rob
2015-03-10 22:30 GMT+01:00 Rob Herring <robherring2@gmail.com>: > On Tue, Mar 10, 2015 at 3:19 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Tuesday 10 March 2015 16:28:44 Maxime Coquelin wrote: >>> 2015-03-10 16:00 GMT+01:00 Arnd Bergmann <arnd@arndb.de>: >>> > On Friday 20 February 2015 19:01:04 Maxime Coquelin wrote: >>> >> Some platforms need to initialize the reset controller before the timers. >>> >> >>> >> This patch introduces a reset_controller_of_init() function that can be >>> >> called before the timers intialization. >>> >> >>> >> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> >>> >> >>> > >>> > Not sure about this. It seems like the cleanest approach if we get >>> > a lot of these, but then again it is probably very rare, and I'd >>> > like to avoid adding such infrastructure if it's just for one >>> > SoC. Could we add a hack in the machine initialization instead? >>> >>> Sun6i also need to initialize the reset controller early. Today, they >>> hack the machine initialization. >>> With two SoCs having the same need, what should we do? >> >> Good question, I'd like to hear some other opinions on this first. > > 2 is still far from the common case. > >>> > I think ideally this would be done in the boot loader before we >>> > even start Linux, but I don't know if that's possible for you. >>> >>> From what I understand, the only constraint is to perform it after the >>> clock is enabled. >>> So this should be possible to do it in the bootloader, but it means >>> also adding timers clocks ungating in the bootloader. >> >> Ungating the timer clock input seems like a reasonable thing to >> do for the bootloader, I think a lot of platforms rely on this >> elsewhere (but enough of them don't, which is why we have the >> early clk init). > > +1 > > If the bootloader is u-boot, then you need a timer anyway. Ok, I moved it to the bootloader, and use the reset as optional in the timer driver. Thanks, Maxime > > Rob
diff --git a/drivers/reset/core.c b/drivers/reset/core.c index 7955e00..7eef63e 100644 --- a/drivers/reset/core.c +++ b/drivers/reset/core.c @@ -86,6 +86,33 @@ void reset_controller_unregister(struct reset_controller_dev *rcdev) } EXPORT_SYMBOL_GPL(reset_controller_unregister); +extern struct of_device_id __reset_ctrl_of_table[]; + +static const struct of_device_id __reset_ctrl_of_table_sentinel + __used __section(__reset_ctrl_of_table_end); + +/** + * reset_controller_of_init - scan and init reset controllers from the DT + * + * This function scas the device tree for matching reset controllers. It is + * used on machines that need reset controls at early stage. To use it, the + * controller driver has to be registred with RESET_CONTROLLER_OF_DECLARE(). + */ +void __init reset_controller_of_init(void) +{ + struct device_node *np; + const struct of_device_id *match; + of_init_fn_1 init_func; + + for_each_matching_node_and_match(np, __reset_ctrl_of_table, &match) { + if (!of_device_is_available(np)) + continue; + + init_func = match->data; + init_func(np); + } +} + /** * reset_control_reset - reset the controlled device * @rstc: reset controller diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index bee5d68..1f96365 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -168,6 +168,7 @@ #define RESERVEDMEM_OF_TABLES() OF_TABLE(CONFIG_OF_RESERVED_MEM, reservedmem) #define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_method) #define EARLYCON_OF_TABLES() OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon) +#define RESET_CTRL_OF_TABLES() OF_TABLE(CONFIG_RESET_CONTROLLER, reset_ctrl) #define KERNEL_DTB() \ STRUCT_ALIGN(); \ @@ -502,7 +503,8 @@ CPU_METHOD_OF_TABLES() \ KERNEL_DTB() \ IRQCHIP_OF_MATCH_TABLE() \ - EARLYCON_OF_TABLES() + EARLYCON_OF_TABLES() \ + RESET_CTRL_OF_TABLES() #define INIT_TEXT \ *(.init.text) \ diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h index ce6b962..f8a030a 100644 --- a/include/linux/reset-controller.h +++ b/include/linux/reset-controller.h @@ -51,4 +51,10 @@ struct reset_controller_dev { int reset_controller_register(struct reset_controller_dev *rcdev); void reset_controller_unregister(struct reset_controller_dev *rcdev); + +#define RESET_CONTROLLER_OF_DECLARE(name, compat, fn) \ + OF_DECLARE_1(reset_ctrl, name, compat, fn) + +void reset_controller_of_init(void); + #endif
Some platforms need to initialize the reset controller before the timers. This patch introduces a reset_controller_of_init() function that can be called before the timers intialization. Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> --- drivers/reset/core.c | 27 +++++++++++++++++++++++++++ include/asm-generic/vmlinux.lds.h | 4 +++- include/linux/reset-controller.h | 6 ++++++ 3 files changed, 36 insertions(+), 1 deletion(-)