Re: [RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE

Re: [RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE

[David Lechner]

FYI: It looks like the CC for Stephen and Arnd was messed up, so I
fixed.

On 04/23/2018 01:38 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> Hi David, Sekhar,
> 
> since platform devices are generally considered more desirable than
> CLK_OF_DECLARE, TIMER_OF_DECLARE etc. and we need to figure out how to
> handle the clocks that need to be initialized early in the boot
> process on DaVinci, I thought that I could give the early_platform
> mechanism a try.
> 
> This API is only used on one architecture (sh) but seems to work just
> fine on ARM. It allows to register early platform drivers and then
> probe them early in the boot process. So far only machine code is
> supported but with a bit of hacking I was able to probe a DT device.
> 
> This is a very dirty and far-from-upstream proof of concept that allows
> to probe the (so far dummy) davinci timer platform device during the
> call to init_time (from machine_desc).
> 
> The idea is to have a special compatible fallback string: "earlydev"
> that similarily to "syscon" would be added to device nodes that need
> early probing. Then we'd call the of_early_platform_populate()
> function that would find all compatible nodes and populate them
> long before all the "normal" nodes.

FWIW, "earlydev" sounds like a driver implementation detail, so not
something that should be included in the device tree. We only need
this because Linux needs a clocksource early on, but that doesn't
mean that all device tree users need to do the same.

I'm sure it makes things easier for a proof of concept though. :-)

> 
> This would allow us to make the davinci timer a normal platform device
> and possibly also probe the psc and pll drivers earlier than we do now.
> 
> The early platform API even allows us to check if we're being probed
> early in probe() so we can possibly probe the driver twice if needed:
> only doing the critical stuff first and then completing the process
> later.
> 
> If you think this is a good idea, I would like to continue on that
> and eventually make it an alternative to OF_DECLARE macros.
> 
> For a quick conversion of the davinci timer to a platform driver
> I image we'd need to use platform data lookup that would be passed
> to of_early_platform_populate().

On the surface, it certainly sounds like a good idea to me. Do we have
access to struct device of the platform device when using this early
platform device? I remember when I was working on the clock drivers, I
tried registering a platform device in the init_time callback but the
kernel crashed because kobj stuff was not initialized yet. I'm guessing
that the early platform device somehow works around this.

[RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE

[David Lechner]

FYI: It looks like the CC for Stephen and Arnd was messed up, so I
fixed.

On 04/23/2018 01:38 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> Hi David, Sekhar,
> 
> since platform devices are generally considered more desirable than
> CLK_OF_DECLARE, TIMER_OF_DECLARE etc. and we need to figure out how to
> handle the clocks that need to be initialized early in the boot
> process on DaVinci, I thought that I could give the early_platform
> mechanism a try.
> 
> This API is only used on one architecture (sh) but seems to work just
> fine on ARM. It allows to register early platform drivers and then
> probe them early in the boot process. So far only machine code is
> supported but with a bit of hacking I was able to probe a DT device.
> 
> This is a very dirty and far-from-upstream proof of concept that allows
> to probe the (so far dummy) davinci timer platform device during the
> call to init_time (from machine_desc).
> 
> The idea is to have a special compatible fallback string: "earlydev"
> that similarily to "syscon" would be added to device nodes that need
> early probing. Then we'd call the of_early_platform_populate()
> function that would find all compatible nodes and populate them
> long before all the "normal" nodes.

FWIW, "earlydev" sounds like a driver implementation detail, so not
something that should be included in the device tree. We only need
this because Linux needs a clocksource early on, but that doesn't
mean that all device tree users need to do the same.

I'm sure it makes things easier for a proof of concept though. :-)

> 
> This would allow us to make the davinci timer a normal platform device
> and possibly also probe the psc and pll drivers earlier than we do now.
> 
> The early platform API even allows us to check if we're being probed
> early in probe() so we can possibly probe the driver twice if needed:
> only doing the critical stuff first and then completing the process
> later.
> 
> If you think this is a good idea, I would like to continue on that
> and eventually make it an alternative to OF_DECLARE macros.
> 
> For a quick conversion of the davinci timer to a platform driver
> I image we'd need to use platform data lookup that would be passed
> to of_early_platform_populate().

On the surface, it certainly sounds like a good idea to me. Do we have
access to struct device of the platform device when using this early
platform device? I remember when I was working on the clock drivers, I
tried registering a platform device in the init_time callback but the
kernel crashed because kobj stuff was not initialized yet. I'm guessing
that the early platform device somehow works around this.

Re: [RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE

[Bartosz Golaszewski]

2018-04-23 23:38 GMT+02:00 David Lechner <david@lechnology.com>:
> FYI: It looks like the CC for Stephen and Arnd was messed up, so I
> fixed.
>

Thanks!

> On 04/23/2018 01:38 PM, Bartosz Golaszewski wrote:
>>
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Hi David, Sekhar,
>>
>> since platform devices are generally considered more desirable than
>> CLK_OF_DECLARE, TIMER_OF_DECLARE etc. and we need to figure out how to
>> handle the clocks that need to be initialized early in the boot
>> process on DaVinci, I thought that I could give the early_platform
>> mechanism a try.
>>
>> This API is only used on one architecture (sh) but seems to work just
>> fine on ARM. It allows to register early platform drivers and then
>> probe them early in the boot process. So far only machine code is
>> supported but with a bit of hacking I was able to probe a DT device.
>>
>> This is a very dirty and far-from-upstream proof of concept that allows
>> to probe the (so far dummy) davinci timer platform device during the
>> call to init_time (from machine_desc).
>>
>> The idea is to have a special compatible fallback string: "earlydev"
>> that similarily to "syscon" would be added to device nodes that need
>> early probing. Then we'd call the of_early_platform_populate()
>> function that would find all compatible nodes and populate them
>> long before all the "normal" nodes.
>
>
> FWIW, "earlydev" sounds like a driver implementation detail, so not
> something that should be included in the device tree. We only need
> this because Linux needs a clocksource early on, but that doesn't
> mean that all device tree users need to do the same.
>
> I'm sure it makes things easier for a proof of concept though. :-)
>

We already have "syscon" which too is more an implementation detail
than HW description. I should have probably Cc'ed Rob Herring. I'll do
it with a more polished version I should have today.

>>
>> This would allow us to make the davinci timer a normal platform device
>> and possibly also probe the psc and pll drivers earlier than we do now.
>>
>> The early platform API even allows us to check if we're being probed
>> early in probe() so we can possibly probe the driver twice if needed:
>> only doing the critical stuff first and then completing the process
>> later.
>>
>> If you think this is a good idea, I would like to continue on that
>> and eventually make it an alternative to OF_DECLARE macros.
>>
>> For a quick conversion of the davinci timer to a platform driver
>> I image we'd need to use platform data lookup that would be passed
>> to of_early_platform_populate().
>
>
> On the surface, it certainly sounds like a good idea to me. Do we have
> access to struct device of the platform device when using this early
> platform device? I remember when I was working on the clock drivers, I
> tried registering a platform device in the init_time callback but the
> kernel crashed because kobj stuff was not initialized yet. I'm guessing
> that the early platform device somehow works around this.
>

Yes, it seems we do. I was getting kobj stack dumps too when trying to
register a device using just platform_device_register() and it went
away as soon as I switched to early platform.

Best regards,
Bartosz Golaszewski

[RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE

[Bartosz Golaszewski]

2018-04-23 23:38 GMT+02:00 David Lechner <david@lechnology.com>:
> FYI: It looks like the CC for Stephen and Arnd was messed up, so I
> fixed.
>

Thanks!

> On 04/23/2018 01:38 PM, Bartosz Golaszewski wrote:
>>
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Hi David, Sekhar,
>>
>> since platform devices are generally considered more desirable than
>> CLK_OF_DECLARE, TIMER_OF_DECLARE etc. and we need to figure out how to
>> handle the clocks that need to be initialized early in the boot
>> process on DaVinci, I thought that I could give the early_platform
>> mechanism a try.
>>
>> This API is only used on one architecture (sh) but seems to work just
>> fine on ARM. It allows to register early platform drivers and then
>> probe them early in the boot process. So far only machine code is
>> supported but with a bit of hacking I was able to probe a DT device.
>>
>> This is a very dirty and far-from-upstream proof of concept that allows
>> to probe the (so far dummy) davinci timer platform device during the
>> call to init_time (from machine_desc).
>>
>> The idea is to have a special compatible fallback string: "earlydev"
>> that similarily to "syscon" would be added to device nodes that need
>> early probing. Then we'd call the of_early_platform_populate()
>> function that would find all compatible nodes and populate them
>> long before all the "normal" nodes.
>
>
> FWIW, "earlydev" sounds like a driver implementation detail, so not
> something that should be included in the device tree. We only need
> this because Linux needs a clocksource early on, but that doesn't
> mean that all device tree users need to do the same.
>
> I'm sure it makes things easier for a proof of concept though. :-)
>

We already have "syscon" which too is more an implementation detail
than HW description. I should have probably Cc'ed Rob Herring. I'll do
it with a more polished version I should have today.

>>
>> This would allow us to make the davinci timer a normal platform device
>> and possibly also probe the psc and pll drivers earlier than we do now.
>>
>> The early platform API even allows us to check if we're being probed
>> early in probe() so we can possibly probe the driver twice if needed:
>> only doing the critical stuff first and then completing the process
>> later.
>>
>> If you think this is a good idea, I would like to continue on that
>> and eventually make it an alternative to OF_DECLARE macros.
>>
>> For a quick conversion of the davinci timer to a platform driver
>> I image we'd need to use platform data lookup that would be passed
>> to of_early_platform_populate().
>
>
> On the surface, it certainly sounds like a good idea to me. Do we have
> access to struct device of the platform device when using this early
> platform device? I remember when I was working on the clock drivers, I
> tried registering a platform device in the init_time callback but the
> kernel crashed because kobj stuff was not initialized yet. I'm guessing
> that the early platform device somehow works around this.
>

Yes, it seems we do. I was getting kobj stack dumps too when trying to
register a device using just platform_device_register() and it went
away as soon as I switched to early platform.

Best regards,
Bartosz Golaszewski

Re: [RFC work-in-progress 5/7] !WIP ARM: davinci: convert da850 to using the davinci clocksource driver

[Sekhar Nori]

On Tuesday 24 April 2018 12:08 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  arch/arm/mach-davinci/da850.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3f27d46ca43f..712964383bc2 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -757,13 +757,28 @@ void __init da850_init(void)
>  	WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module");
>  }
>  
> +static struct platform_device da850_timer_device = {
> +	.name			= "timer-davinci",
> +	.id			= -1,
> +};
> +
>  void __init da850_init_time(void)
>  {
>  	struct clk *clk;
> +	int ret;
>  
>  	clk = clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DA850_REF_FREQ);
>  
>  	davinci_timer_init(clk);
> +
> +	ret = clk_register_clkdev(clk, NULL, "timer-davinci");
> +	if (ret) {
> +		pr_err("%s: error registering ref_clk: %d", __func__, ret);
> +		return;
> +	}

This part had to be added because you don't have clocks converted to
early platform devices in your branch, right?

Thanks,
Sekhar

[RFC work-in-progress 5/7] !WIP ARM: davinci: convert da850 to using the davinci clocksource driver

[Sekhar Nori]

On Tuesday 24 April 2018 12:08 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  arch/arm/mach-davinci/da850.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3f27d46ca43f..712964383bc2 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -757,13 +757,28 @@ void __init da850_init(void)
>  	WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module");
>  }
>  
> +static struct platform_device da850_timer_device = {
> +	.name			= "timer-davinci",
> +	.id			= -1,
> +};
> +
>  void __init da850_init_time(void)
>  {
>  	struct clk *clk;
> +	int ret;
>  
>  	clk = clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DA850_REF_FREQ);
>  
>  	davinci_timer_init(clk);
> +
> +	ret = clk_register_clkdev(clk, NULL, "timer-davinci");
> +	if (ret) {
> +		pr_err("%s: error registering ref_clk: %d", __func__, ret);
> +		return;
> +	}

This part had to be added because you don't have clocks converted to
early platform devices in your branch, right?

Thanks,
Sekhar

Re: [RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE

[Sekhar Nori]

On Tuesday 24 April 2018 12:56 PM, Bartosz Golaszewski wrote:
> 2018-04-23 23:38 GMT+02:00 David Lechner <david@lechnology.com>:
>> FYI: It looks like the CC for Stephen and Arnd was messed up, so I
>> fixed.
>>
> 
> Thanks!
> 
>> On 04/23/2018 01:38 PM, Bartosz Golaszewski wrote:
>>>
>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>
>>> Hi David, Sekhar,
>>>
>>> since platform devices are generally considered more desirable than
>>> CLK_OF_DECLARE, TIMER_OF_DECLARE etc. and we need to figure out how to
>>> handle the clocks that need to be initialized early in the boot
>>> process on DaVinci, I thought that I could give the early_platform
>>> mechanism a try.
>>>
>>> This API is only used on one architecture (sh) but seems to work just
>>> fine on ARM. It allows to register early platform drivers and then
>>> probe them early in the boot process. So far only machine code is
>>> supported but with a bit of hacking I was able to probe a DT device.
>>>
>>> This is a very dirty and far-from-upstream proof of concept that allows
>>> to probe the (so far dummy) davinci timer platform device during the
>>> call to init_time (from machine_desc).
>>>
>>> The idea is to have a special compatible fallback string: "earlydev"
>>> that similarily to "syscon" would be added to device nodes that need
>>> early probing. Then we'd call the of_early_platform_populate()
>>> function that would find all compatible nodes and populate them
>>> long before all the "normal" nodes.
>>
>>
>> FWIW, "earlydev" sounds like a driver implementation detail, so not
>> something that should be included in the device tree. We only need
>> this because Linux needs a clocksource early on, but that doesn't
>> mean that all device tree users need to do the same.
>>
>> I'm sure it makes things easier for a proof of concept though. :-)
>>
> 
> We already have "syscon" which too is more an implementation detail
> than HW description. I should have probably Cc'ed Rob Herring. I'll do
> it with a more polished version I should have today.

Yeah, we should check with DT maintainers here. Even if there is push
back on this, I suppose we can make of_early_platform_populate() take a
list of compatible strings whose DT nodes should be considered early
platform devices?

>>> This would allow us to make the davinci timer a normal platform device
>>> and possibly also probe the psc and pll drivers earlier than we do now.
>>>
>>> The early platform API even allows us to check if we're being probed
>>> early in probe() so we can possibly probe the driver twice if needed:
>>> only doing the critical stuff first and then completing the process
>>> later.
>>>
>>> If you think this is a good idea, I would like to continue on that
>>> and eventually make it an alternative to OF_DECLARE macros.
>>>
>>> For a quick conversion of the davinci timer to a platform driver
>>> I image we'd need to use platform data lookup that would be passed
>>> to of_early_platform_populate().
>>
>>
>> On the surface, it certainly sounds like a good idea to me. Do we have
>> access to struct device of the platform device when using this early
>> platform device? I remember when I was working on the clock drivers, I
>> tried registering a platform device in the init_time callback but the
>> kernel crashed because kobj stuff was not initialized yet. I'm guessing
>> that the early platform device somehow works around this.
>>
> 
> Yes, it seems we do. I was getting kobj stack dumps too when trying to
> register a device using just platform_device_register() and it went
> away as soon as I switched to early platform.

I agree, it sounds like a good idea to use for clock and timer devices.
Thanks for looking into this. Looking forward to the more polished version.

Thanks,
Sekhar

[RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE

[Sekhar Nori]

On Tuesday 24 April 2018 12:56 PM, Bartosz Golaszewski wrote:
> 2018-04-23 23:38 GMT+02:00 David Lechner <david@lechnology.com>:
>> FYI: It looks like the CC for Stephen and Arnd was messed up, so I
>> fixed.
>>
> 
> Thanks!
> 
>> On 04/23/2018 01:38 PM, Bartosz Golaszewski wrote:
>>>
>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>
>>> Hi David, Sekhar,
>>>
>>> since platform devices are generally considered more desirable than
>>> CLK_OF_DECLARE, TIMER_OF_DECLARE etc. and we need to figure out how to
>>> handle the clocks that need to be initialized early in the boot
>>> process on DaVinci, I thought that I could give the early_platform
>>> mechanism a try.
>>>
>>> This API is only used on one architecture (sh) but seems to work just
>>> fine on ARM. It allows to register early platform drivers and then
>>> probe them early in the boot process. So far only machine code is
>>> supported but with a bit of hacking I was able to probe a DT device.
>>>
>>> This is a very dirty and far-from-upstream proof of concept that allows
>>> to probe the (so far dummy) davinci timer platform device during the
>>> call to init_time (from machine_desc).
>>>
>>> The idea is to have a special compatible fallback string: "earlydev"
>>> that similarily to "syscon" would be added to device nodes that need
>>> early probing. Then we'd call the of_early_platform_populate()
>>> function that would find all compatible nodes and populate them
>>> long before all the "normal" nodes.
>>
>>
>> FWIW, "earlydev" sounds like a driver implementation detail, so not
>> something that should be included in the device tree. We only need
>> this because Linux needs a clocksource early on, but that doesn't
>> mean that all device tree users need to do the same.
>>
>> I'm sure it makes things easier for a proof of concept though. :-)
>>
> 
> We already have "syscon" which too is more an implementation detail
> than HW description. I should have probably Cc'ed Rob Herring. I'll do
> it with a more polished version I should have today.

Yeah, we should check with DT maintainers here. Even if there is push
back on this, I suppose we can make of_early_platform_populate() take a
list of compatible strings whose DT nodes should be considered early
platform devices?

>>> This would allow us to make the davinci timer a normal platform device
>>> and possibly also probe the psc and pll drivers earlier than we do now.
>>>
>>> The early platform API even allows us to check if we're being probed
>>> early in probe() so we can possibly probe the driver twice if needed:
>>> only doing the critical stuff first and then completing the process
>>> later.
>>>
>>> If you think this is a good idea, I would like to continue on that
>>> and eventually make it an alternative to OF_DECLARE macros.
>>>
>>> For a quick conversion of the davinci timer to a platform driver
>>> I image we'd need to use platform data lookup that would be passed
>>> to of_early_platform_populate().
>>
>>
>> On the surface, it certainly sounds like a good idea to me. Do we have
>> access to struct device of the platform device when using this early
>> platform device? I remember when I was working on the clock drivers, I
>> tried registering a platform device in the init_time callback but the
>> kernel crashed because kobj stuff was not initialized yet. I'm guessing
>> that the early platform device somehow works around this.
>>
> 
> Yes, it seems we do. I was getting kobj stack dumps too when trying to
> register a device using just platform_device_register() and it went
> away as soon as I switched to early platform.

I agree, it sounds like a good idea to use for clock and timer devices.
Thanks for looking into this. Looking forward to the more polished version.

Thanks,
Sekhar

Re: [RFC work-in-progress 5/7] !WIP ARM: davinci: convert da850 to using the davinci clocksource driver

[Bartosz Golaszewski]

2018-04-24 10:10 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> On Tuesday 24 April 2018 12:08 AM, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>>  arch/arm/mach-davinci/da850.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index 3f27d46ca43f..712964383bc2 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -757,13 +757,28 @@ void __init da850_init(void)
>>       WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module");
>>  }
>>
>> +static struct platform_device da850_timer_device = {
>> +     .name                   = "timer-davinci",
>> +     .id                     = -1,
>> +};
>> +
>>  void __init da850_init_time(void)
>>  {
>>       struct clk *clk;
>> +     int ret;
>>
>>       clk = clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DA850_REF_FREQ);
>>
>>       davinci_timer_init(clk);
>> +
>> +     ret = clk_register_clkdev(clk, NULL, "timer-davinci");
>> +     if (ret) {
>> +             pr_err("%s: error registering ref_clk: %d", __func__, ret);
>> +             return;
>> +     }
>
> This part had to be added because you don't have clocks converted to
> early platform devices in your branch, right?
>
> Thanks,
> Sekhar

Yes. Also: I've stumbled upon some problems with the current
implementation of early platform drivers making simple conversion of
psc and pll to early devices impossible. I've mostly fixed them and
hope to be able to send something today or early tomorrow.

Bart

[RFC work-in-progress 5/7] !WIP ARM: davinci: convert da850 to using the davinci clocksource driver

[Bartosz Golaszewski]

2018-04-24 10:10 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> On Tuesday 24 April 2018 12:08 AM, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>>  arch/arm/mach-davinci/da850.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index 3f27d46ca43f..712964383bc2 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -757,13 +757,28 @@ void __init da850_init(void)
>>       WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module");
>>  }
>>
>> +static struct platform_device da850_timer_device = {
>> +     .name                   = "timer-davinci",
>> +     .id                     = -1,
>> +};
>> +
>>  void __init da850_init_time(void)
>>  {
>>       struct clk *clk;
>> +     int ret;
>>
>>       clk = clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DA850_REF_FREQ);
>>
>>       davinci_timer_init(clk);
>> +
>> +     ret = clk_register_clkdev(clk, NULL, "timer-davinci");
>> +     if (ret) {
>> +             pr_err("%s: error registering ref_clk: %d", __func__, ret);
>> +             return;
>> +     }
>
> This part had to be added because you don't have clocks converted to
> early platform devices in your branch, right?
>
> Thanks,
> Sekhar

Yes. Also: I've stumbled upon some problems with the current
implementation of early platform drivers making simple conversion of
psc and pll to early devices impossible. I've mostly fixed them and
hope to be able to send something today or early tomorrow.

Bart