freemangordon | tmlind: any idea https://pastebin.com/WPAruC7C? | 00:08 |
---|---|---|
freemangordon | seems pwm_apply_state() cannot be called from atomic context | 00:10 |
tmlind | freemangordon: no idea.. but clk_prepare can sleep, maybe it can be done with separate clk_prepare() & clk_enable() calls? | 08:22 |
freemangordon | actually dmtimer tries to get the functional clock rate | 08:24 |
tmlind | seems like that should not change and could be done earlier during init or something? | 08:25 |
freemangordon | here: https://elixir.bootlin.com/linux/v6.1.48/source/drivers/clocksource/timer-ti-dm.c#L754 | 08:26 |
freemangordon | right | 08:26 |
freemangordon | I was thinking about that | 08:26 |
freemangordon | or, register frequency notifier? | 08:26 |
freemangordon | tmlind: what about getting the freq on init an doing devm_clk_notifier_register() ? | 08:28 |
tmlind | stash rate on register, update it in case change_rate happens, read it on stop for the delay needed? | 08:29 |
freemangordon | that way no clk_get_rate() will be needed | 08:30 |
tmlind | yeah | 08:30 |
freemangordon | but what if someone else changes the fclk frequency? | 08:30 |
freemangordon | I mean, if I dont register notifier | 08:30 |
tmlind | fclk is claimed by the dmtimer only afaik? | 08:30 |
tmlind | maybe add a comment on the possible need for a notifier | 08:31 |
freemangordon | is there any issue if I go for notifier directly? it seems easier to me | 08:32 |
tmlind | sounds good to me | 08:32 |
freemangordon | ok, but I can't find if pwm_apply_state() can be called from atomic context | 08:33 |
tmlind | no idea, probably changing state in an interrupt is needed though.. | 08:33 |
tmlind | for rate changes etc | 08:33 |
freemangordon | in case API does not allow it, making dmtimer not sleeping does not make sense | 08:33 |
tmlind | ok | 08:34 |
tmlind | putting together a branch on v6.6-rc1 here fyi.. still need to deal with the modem stuff at least so probably not done until next week at some point | 08:35 |
tmlind | freemangordon: hmm any plans on moving pvr mesa to use the legacy mesa amber branch? seems that would provide a stable base with fixes backported.. | 08:35 |
freemangordon | no idea :) | 08:36 |
tmlind | ok | 08:36 |
freemangordon | but maybe we will have to | 08:36 |
freemangordon | tmlind: so, according to https://github.com/torvalds/linux/blob/master/drivers/pwm/core.c#L502, I should not call pwm_apply_state() from irq handler | 08:39 |
tmlind | ok | 08:39 |
freemangordon | tmlind: any idea how fast wait queues are? Like, do we expect big delay between wake_up_xxx() call and waiting thread being resumed? | 11:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!