public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: grinberg@compulab•co.il (Igor Grinberg)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
Date: Wed, 14 Nov 2012 09:23:57 +0200	[thread overview]
Message-ID: <50A3470D.3050202@compulab.co.il> (raw)
In-Reply-To: <50A271A7.2000305@ti.com>

On 11/13/12 18:13, Jon Hunter wrote:
> 
> On 11/13/2012 03:14 AM, Igor Grinberg wrote:
>> On 11/12/12 21:15, Jon Hunter wrote:
>>>
>>> On 11/11/2012 05:28 AM, Igor Grinberg wrote:
>>>>
>>>>
>>>> On 11/08/12 21:16, Jon Hunter wrote:
>>>>>
>>>>> On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote:
>>>>>> On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote:
>>>>>>>
>>>>>>> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
>>>>>>>
>>>>>>> [snip]
>>>>>>>
>>>>>>>> There is no reliable way to determine which source should be used in runtime
>>>>>>>> for boards that do not have the 32k oscillator wired.
>>>>>>>
>>>>>>> So thinking about this some more and given that we are moving away from
>>>>>>> board files, if a board does not provide a 32kHz clock source, then this
>>>>>>> should be reflected in the device-tree source file for that board.
>>>>>>> Hence, at boot time we should be able to determine if a 32kHz clock
>>>>>>> source can be used.
>>>>>>>
>>>>>>
>>>>>> Let me feed some more thoughts here :)
>>>>>>
>>>>>> The way it is being detected currently is based on timer idle status bit.
>>>>>> I am worried that, this is the only option we have.
>>>>>
>>>>> Why not use device-tree to indicate the presence of a 32k clock source?
>>>>> This seems like a board level configuration and so device-tree seems to
>>>>> be the perfect place for this IMO.
>>>>
>>>> Well, that is what my commit message says...
>>>
>>> Sorry, but that was not clear to me from whats in the commit message.
>>
>> From the commit message:
>> "1) Timer structures and initialization functions are named by the platform
>>    name and the clock source in use. The decision which timer is
>>    used is done statically from the machine_desc structure. In the
>>    future it should come from DT."
>>
>> The last sentence has it.
> 
> Right, but it does not go into the details. It would be good to have
> added a comment to the effect of "some boards do not have a 32k clock
> source and in the future this should be handled by device-tree".

Ok.

> 
>> The transition to DT is not immediate and we can't (still) neglect
>> the non-DT setups.
> 
> Absolutely, but I am trying to understand if there are boards being
> "neglected". I see now that your CM-T3517 would be. This was not clear
> from your patch as even the CM-T3517 board was being configured to the
> use the sync32k timer. So from looking at your patch I did not see any
> neglected boards, however, I understand your motivation to add all these
> init functions so that boards could be customised easily.

I did not changed the CM-T3517, because I believe it should be done
in a separate patch.

> 
>>> Should we be doing this now instead of adding all these static timer
>>> init functions?
>>
>> I don't see this as "adding ...", I see this as expanding the setup
>> which was previously hidden by the CONFIG_OMAP_32K_TIMER option.
>>
>>>
>>> Are there any boards today (supported in the kernel that is), that don't
>>> support a 32k?
>>
>> Yes, starting from revision 1.2, CM-T3517 does not have the 32k.
> 
> Thanks, this is the exact information I was looking for. You should put
> this in your commit message to highlight the fact that there are boards
> that don't have a 32k clock source.
> 
> I am familiar with the OMAP devices, but less familiar with these AMxxxx
> derivatives (as I don't work with these) and so it is good to put these
> specifics in the commit message.

Ok.


-- 
Regards,
Igor.

  reply	other threads:[~2012-11-14  7:23 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07 14:42 [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER Igor Grinberg
2012-11-07 17:33 ` Tony Lindgren
2012-11-08  7:13   ` Igor Grinberg
2012-11-08 16:20     ` Tony Lindgren
2012-11-08 17:09       ` Hiremath, Vaibhav
2012-11-11  9:16       ` Igor Grinberg
2012-11-12 19:05         ` Jon Hunter
2012-11-13  9:08           ` Igor Grinberg
2012-11-12 22:06         ` Tony Lindgren
2012-11-07 21:36 ` Jon Hunter
2012-11-08  7:59   ` Igor Grinberg
2012-11-08 16:16     ` Jon Hunter
2012-11-08 17:08       ` Hiremath, Vaibhav
2012-11-08 17:39         ` Jon Hunter
2012-11-08 17:47           ` Hiremath, Vaibhav
2012-11-08 17:58             ` Jon Hunter
2012-11-08 18:06               ` Hiremath, Vaibhav
2012-11-08 18:13                 ` Jon Hunter
2012-11-08 18:28                   ` Hiremath, Vaibhav
2012-11-08 18:47                     ` Jon Hunter
2012-11-09  0:55                 ` Jon Hunter
2012-11-12  6:42                   ` Hiremath, Vaibhav
2012-11-08 17:58           ` Paul Walmsley
2012-11-08 18:08             ` Jon Hunter
2012-11-08 18:17               ` Paul Walmsley
2012-11-08 18:34                 ` Jon Hunter
2012-11-11 11:35                   ` Igor Grinberg
2012-11-12  6:38                     ` Hiremath, Vaibhav
2012-11-12  7:24                       ` Igor Grinberg
2012-11-12 10:40                         ` Hiremath, Vaibhav
2012-12-10 20:49                     ` Paul Walmsley
2012-12-14 23:58         ` Russ Dill
2012-11-11 11:25       ` Igor Grinberg
2012-11-08 18:54     ` Jon Hunter
2012-11-08 18:59       ` Hiremath, Vaibhav
2012-11-08 19:16         ` Jon Hunter
2012-11-11 11:28           ` Igor Grinberg
2012-11-12 19:15             ` Jon Hunter
2012-11-13  9:14               ` Igor Grinberg
2012-11-13 16:13                 ` Jon Hunter
2012-11-14  7:23                   ` Igor Grinberg [this message]
2012-11-12 10:38           ` Hiremath, Vaibhav
2012-11-12 11:01             ` Benoit Cousson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A3470D.3050202@compulab.co.il \
    --to=grinberg@compulab$(echo .)co.il \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox