| Message ID | 1476561450-28407-2-git-send-email-robert.jarzmik@free.fr (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On 15-10-16, 21:57, Robert Jarzmik wrote: > For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is > doing the job as well as pxa2xx-cpufreq, so add these platforms to the > compatibility list. > > This won't work for legacy non device-tree platforms where > pxa2xx-cpufreq is still required. > > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> > --- > drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c > index 0bb44d5b5df4..356825b5c9b8 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = { > { .compatible = "fsl,imx7d", }, > > { .compatible = "marvell,berlin", }, > + { .compatible = "marvell,pxa250", }, > + { .compatible = "marvell,pxa270", }, > > { .compatible = "samsung,exynos3250", }, > { .compatible = "samsung,exynos4210", }, Isn't there a race between cpufreq-dt and the platform driver to register first ? Also, it seems that atleast the next two patches are required before applying this? You need to fix the order if that is the case.
Viresh Kumar <viresh.kumar@linaro.org> writes: > On 15-10-16, 21:57, Robert Jarzmik wrote: >> For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is >> doing the job as well as pxa2xx-cpufreq, so add these platforms to the >> compatibility list. >> >> This won't work for legacy non device-tree platforms where >> pxa2xx-cpufreq is still required. >> >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> >> --- >> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c >> index 0bb44d5b5df4..356825b5c9b8 100644 >> --- a/drivers/cpufreq/cpufreq-dt-platdev.c >> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c >> @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = { >> { .compatible = "fsl,imx7d", }, >> >> { .compatible = "marvell,berlin", }, >> + { .compatible = "marvell,pxa250", }, >> + { .compatible = "marvell,pxa270", }, >> >> { .compatible = "samsung,exynos3250", }, >> { .compatible = "samsung,exynos4210", }, > > Isn't there a race between cpufreq-dt and the platform driver to > register first ? Ah, could you be more specific about the race you're talking of ? My understanding was that cpufreq-dt-platdev does create the device, and cpufreq-dt is a driver for it, so there is no race but a direct relationship AFAIU. > Also, it seems that atleast the next two patches are required before > applying this? You need to fix the order if that is the case. Ok, as you wish, let it become number 3 and (2, 3) become (1, 2). Cheers.
On 18-10-16, 17:35, Robert Jarzmik wrote: > Viresh Kumar <viresh.kumar@linaro.org> writes: > > > On 15-10-16, 21:57, Robert Jarzmik wrote: > >> For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is > >> doing the job as well as pxa2xx-cpufreq, so add these platforms to the > >> compatibility list. > >> > >> This won't work for legacy non device-tree platforms where > >> pxa2xx-cpufreq is still required. > >> > >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> > >> --- > >> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c > >> index 0bb44d5b5df4..356825b5c9b8 100644 > >> --- a/drivers/cpufreq/cpufreq-dt-platdev.c > >> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > >> @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = { > >> { .compatible = "fsl,imx7d", }, > >> > >> { .compatible = "marvell,berlin", }, > >> + { .compatible = "marvell,pxa250", }, > >> + { .compatible = "marvell,pxa270", }, > >> > >> { .compatible = "samsung,exynos3250", }, > >> { .compatible = "samsung,exynos4210", }, > > > > Isn't there a race between cpufreq-dt and the platform driver to > > register first ? > Ah, could you be more specific about the race you're talking of ? > > My understanding was that cpufreq-dt-platdev does create the device, and > cpufreq-dt is a driver for it, so there is no race but a direct relationship > AFAIU. I mean that both the driver may try to register to the cpufreq core if they are both compiled in a single image.
Viresh Kumar <viresh.kumar@linaro.org> writes: >> >> + { .compatible = "marvell,pxa250", }, >> >> + { .compatible = "marvell,pxa270", }, >> >> >> >> { .compatible = "samsung,exynos3250", }, >> >> { .compatible = "samsung,exynos4210", }, >> > >> > Isn't there a race between cpufreq-dt and the platform driver to >> > register first ? >> Ah, could you be more specific about the race you're talking of ? >> >> My understanding was that cpufreq-dt-platdev does create the device, and >> cpufreq-dt is a driver for it, so there is no race but a direct relationship >> AFAIU. > > I mean that both the driver may try to register to the cpufreq core if > they are both compiled in a single image. Euh I still don't follow you. The only driver that can register to the cpufreq core is cpufreq-dt. Now the only case I see is that there are 2 cpufreq-dt platform_device created from cpufreq-dt-platdev. Given that there is only 1 call to platform_device_register_data() in it, I don't see how it is possible. Now if you are worried that 2 cpufreq-dt devices are created, ie. 1 for pxa25x and one for pxa27x: - this looks impossible given the cpufreq_dt_platdev_init() code - no device-tree will ever be compatible with both of them, even if a single kernel binary will be compatible with both of them Tell me if this is the information you're looking for. Cheers.
On 19-10-16, 22:06, Robert Jarzmik wrote: > Viresh Kumar <viresh.kumar@linaro.org> writes: > > >> >> + { .compatible = "marvell,pxa250", }, > >> >> + { .compatible = "marvell,pxa270", }, > >> >> > >> >> { .compatible = "samsung,exynos3250", }, > >> >> { .compatible = "samsung,exynos4210", }, > >> > > >> > Isn't there a race between cpufreq-dt and the platform driver to > >> > register first ? > >> Ah, could you be more specific about the race you're talking of ? > >> > >> My understanding was that cpufreq-dt-platdev does create the device, and > >> cpufreq-dt is a driver for it, so there is no race but a direct relationship > >> AFAIU. > > > > I mean that both the driver may try to register to the cpufreq core if > > they are both compiled in a single image. > Euh I still don't follow you. The only driver that can register to the cpufreq > core is cpufreq-dt. I was wondering on what will happen if both cpufreq-dt and your pxa2xx-cpufreq driver are present in the same kernel image. In that case the init routines of both of them will try to call cpufreq_register_driver().
Viresh Kumar <viresh.kumar@linaro.org> writes: > On 19-10-16, 22:06, Robert Jarzmik wrote: >> Viresh Kumar <viresh.kumar@linaro.org> writes: >> >> >> >> + { .compatible = "marvell,pxa250", }, >> >> >> + { .compatible = "marvell,pxa270", }, >> >> >> >> >> >> { .compatible = "samsung,exynos3250", }, >> >> >> { .compatible = "samsung,exynos4210", }, >> >> > >> >> > Isn't there a race between cpufreq-dt and the platform driver to >> >> > register first ? >> >> Ah, could you be more specific about the race you're talking of ? >> >> >> >> My understanding was that cpufreq-dt-platdev does create the device, and >> >> cpufreq-dt is a driver for it, so there is no race but a direct relationship >> >> AFAIU. >> > >> > I mean that both the driver may try to register to the cpufreq core if >> > they are both compiled in a single image. >> Euh I still don't follow you. The only driver that can register to the cpufreq >> core is cpufreq-dt. > > I was wondering on what will happen if both cpufreq-dt and your pxa2xx-cpufreq > driver are present in the same kernel image. In that case the init routines of > both of them will try to call cpufreq_register_driver(). Right. In my case, cpufreq-dt comes first, and wins. pxa_cpu_init() calls cpufreq_register_driver() and returns -EEXIST. Cheers.
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c index 0bb44d5b5df4..356825b5c9b8 100644 --- a/drivers/cpufreq/cpufreq-dt-platdev.c +++ b/drivers/cpufreq/cpufreq-dt-platdev.c @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = { { .compatible = "fsl,imx7d", }, { .compatible = "marvell,berlin", }, + { .compatible = "marvell,pxa250", }, + { .compatible = "marvell,pxa270", }, { .compatible = "samsung,exynos3250", }, { .compatible = "samsung,exynos4210", },
For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is doing the job as well as pxa2xx-cpufreq, so add these platforms to the compatibility list. This won't work for legacy non device-tree platforms where pxa2xx-cpufreq is still required. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> --- drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++ 1 file changed, 2 insertions(+)