| Message ID | 1382459560-26596-3-git-send-email-jhovold@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Oct 22, 2013 at 06:32:40PM +0200, Johan Hovold wrote: > Even with the atmel_pwm driver and the atmel-pwm-bl backlight driver > supporting deferred probing, we still want to make sure that any > pwm-device is available when the backlight devices are probed to avoid > any unnecessary delays before enabling the backlight. > > Signed-off-by: Johan Hovold <jhovold@gmail.com> > --- > drivers/misc/atmel_pwm.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/drivers/misc/atmel_pwm.c b/drivers/misc/atmel_pwm.c > index a6dc56e..0d0f599 100644 > --- a/drivers/misc/atmel_pwm.c > +++ b/drivers/misc/atmel_pwm.c > @@ -395,7 +395,17 @@ static struct platform_driver atmel_pwm_driver = { > */ > }; > > -module_platform_driver_probe(atmel_pwm_driver, pwm_probe); > +static int __init pwm_init(void) > +{ > + return platform_driver_probe(&atmel_pwm_driver, pwm_probe); > +} > +subsys_initcall(pwm_init); I really hate this type of patch, as it's papering over the real problem. What happens when someone else moves their driver to this level? Then you are back to the original problem. This is what deferred probing was supposed to fix. If it doesn't, then something else needs to be done, or fix the deferred probing mess... Sorry, I can't take this. greg k-h
On Tue, Oct 29, 2013 at 04:22:49PM -0700, Greg KH wrote: > On Tue, Oct 22, 2013 at 06:32:40PM +0200, Johan Hovold wrote: > > Even with the atmel_pwm driver and the atmel-pwm-bl backlight driver > > supporting deferred probing, we still want to make sure that any > > pwm-device is available when the backlight devices are probed to avoid > > any unnecessary delays before enabling the backlight. > > > > Signed-off-by: Johan Hovold <jhovold@gmail.com> > > --- > > drivers/misc/atmel_pwm.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/misc/atmel_pwm.c b/drivers/misc/atmel_pwm.c > > index a6dc56e..0d0f599 100644 > > --- a/drivers/misc/atmel_pwm.c > > +++ b/drivers/misc/atmel_pwm.c > > @@ -395,7 +395,17 @@ static struct platform_driver atmel_pwm_driver = { > > */ > > }; > > > > -module_platform_driver_probe(atmel_pwm_driver, pwm_probe); > > +static int __init pwm_init(void) > > +{ > > + return platform_driver_probe(&atmel_pwm_driver, pwm_probe); > > +} > > +subsys_initcall(pwm_init); > > I really hate this type of patch, as it's papering over the real > problem. What happens when someone else moves their driver to this > level? Then you are back to the original problem. Yes, it's crude, but it's currently the only way to express a preferred probe order. > This is what deferred probing was supposed to fix. If it doesn't, then > something else needs to be done, or fix the deferred probing mess... Deferred probing (the first patch) fixes the dependency problem, but may introduce delays. I can live with that. > Sorry, I can't take this. Fair enough. Thanks, Johan
On Wednesday 30 October 2013, Johan Hovold wrote: > > I really hate this type of patch, as it's papering over the real > > problem. What happens when someone else moves their driver to this > > level? Then you are back to the original problem. > > Yes, it's crude, but it's currently the only way to express a preferred > probe order. Does the same problem occur with the generic PWM subsystem? The atmel_pwm driver apparently is the last PWM driver that has not been converted to the generic subsystem yet. Doing that would also let us drop the atmel-pwm-bl driver in favor of the generic backlight. Arnd
Hi Arnd, On 10/31/2013 04:46, Arnd Bergmann wrote: > On Wednesday 30 October 2013, Johan Hovold wrote: >>> I really hate this type of patch, as it's papering over the real >>> problem. What happens when someone else moves their driver to this >>> level? Then you are back to the original problem. >> >> Yes, it's crude, but it's currently the only way to express a preferred >> probe order. > > Does the same problem occur with the generic PWM subsystem? > > The atmel_pwm driver apparently is the last PWM driver that has > not been converted to the generic subsystem yet. Doing that would > also let us drop the atmel-pwm-bl driver in favor of the generic > backlight. The atmel pwm driver is on the way to generic subsystem. more information at: --->8--- PWM: atmel-pwm: add PWM controller driver: https://patchwork.kernel.org/patch/2963081/ ---<8--- Best Regards, Bo Shen
On 09:19 Thu 31 Oct , Bo Shen wrote: > Hi Arnd, > > On 10/31/2013 04:46, Arnd Bergmann wrote: > >On Wednesday 30 October 2013, Johan Hovold wrote: > >>>I really hate this type of patch, as it's papering over the real > >>>problem. What happens when someone else moves their driver to this > >>>level? Then you are back to the original problem. > >> > >>Yes, it's crude, but it's currently the only way to express a preferred > >>probe order. > > > >Does the same problem occur with the generic PWM subsystem? > > > >The atmel_pwm driver apparently is the last PWM driver that has > >not been converted to the generic subsystem yet. Doing that would > >also let us drop the atmel-pwm-bl driver in favor of the generic > >backlight. > > The atmel pwm driver is on the way to generic subsystem. more > information at: > --->8--- > PWM: atmel-pwm: add PWM controller driver: > https://patchwork.kernel.org/patch/2963081/ so the fix can be drop in favor of the conversion Best Regards, J. > ---<8--- > > Best Regards, > Bo Shen > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Oct 30, 2013 at 09:46:17PM +0100, Arnd Bergmann wrote: > On Wednesday 30 October 2013, Johan Hovold wrote: > > > I really hate this type of patch, as it's papering over the real > > > problem. What happens when someone else moves their driver to this > > > level? Then you are back to the original problem. > > > > Yes, it's crude, but it's currently the only way to express a preferred > > probe order. > > Does the same problem occur with the generic PWM subsystem? It does not suffer from the problem with failed probe as it supports deferred probing, but there could be added delays depending on probe order. > The atmel_pwm driver apparently is the last PWM driver that has > not been converted to the generic subsystem yet. Doing that would > also let us drop the atmel-pwm-bl driver in favor of the generic > backlight. As Bo mentioned, it's work in progress that hasn't been merged yet. Johan
On Thu, Oct 31, 2013 at 06:30:37AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 09:19 Thu 31 Oct , Bo Shen wrote: > > Hi Arnd, > > > > On 10/31/2013 04:46, Arnd Bergmann wrote: > > >On Wednesday 30 October 2013, Johan Hovold wrote: > > >>>I really hate this type of patch, as it's papering over the real > > >>>problem. What happens when someone else moves their driver to this > > >>>level? Then you are back to the original problem. > > >> > > >>Yes, it's crude, but it's currently the only way to express a preferred > > >>probe order. > > > > > >Does the same problem occur with the generic PWM subsystem? > > > > > >The atmel_pwm driver apparently is the last PWM driver that has > > >not been converted to the generic subsystem yet. Doing that would > > >also let us drop the atmel-pwm-bl driver in favor of the generic > > >backlight. > > > > The atmel pwm driver is on the way to generic subsystem. more > > information at: > > --->8--- > > PWM: atmel-pwm: add PWM controller driver: > > https://patchwork.kernel.org/patch/2963081/ > > so the fix can be drop in favor of the conversion This patch (2/2) has been dropped, but the dependency issue still has to be addressed (by adding deferred-probing support). The atmel-pwm-bl driver has not been removed yet and the fix is also needed in stable. Johan
diff --git a/drivers/misc/atmel_pwm.c b/drivers/misc/atmel_pwm.c index a6dc56e..0d0f599 100644 --- a/drivers/misc/atmel_pwm.c +++ b/drivers/misc/atmel_pwm.c @@ -395,7 +395,17 @@ static struct platform_driver atmel_pwm_driver = { */ }; -module_platform_driver_probe(atmel_pwm_driver, pwm_probe); +static int __init pwm_init(void) +{ + return platform_driver_probe(&atmel_pwm_driver, pwm_probe); +} +subsys_initcall(pwm_init); + +static void __exit pwm_exit(void) +{ + platform_driver_unregister(&atmel_pwm_driver); +} +module_exit(pwm_exit); MODULE_DESCRIPTION("Driver for AT32/AT91 PWM module"); MODULE_LICENSE("GPL");
Even with the atmel_pwm driver and the atmel-pwm-bl backlight driver supporting deferred probing, we still want to make sure that any pwm-device is available when the backlight devices are probed to avoid any unnecessary delays before enabling the backlight. Signed-off-by: Johan Hovold <jhovold@gmail.com> --- drivers/misc/atmel_pwm.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)