lkml.org 
[lkml]   [2017]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] ARM: at91: Document new TCB bindings
From
Date
On 13/03/2017 16:18, Nicolas Ferre wrote:
> Le 25/01/2017 à 16:11, Boris Brezillon a écrit :
>> Hi Rob,
>>
>> Sorry to revive this old discussion, but there's still one aspect I'm
>> not sure about.
>>
>> On Tue, 5 Jul 2016 10:40:22 -0500
>> Rob Herring <robh@kernel.org> wrote:
>>
>>>>>> + - compatible: Should be "atmel,tcb-free-running-timer"
>>>>>> + - reg: Should contain the TCB channels to be used. If the
>>>>>> + counter width is 16 bits (at91rm9200-tcb), two consecutive
>>>>>> + channels are needed. Else, only one channel will be used.
>>>>>> +
>>>>>> + * a clockevent device
>>>>>> + - compatible: Should be "atmel,tcb-programmable-timer"
>>>>>
>>>>> This still looks like assigning usage in DT. As I'm willing to accept
>>>>> that for PWM, either timer channels should be whatever channels are not
>>>>> assigned to PWM (i.e. not in DT) or they should just be "timer" and let
>>>>> the kernel decide their usage.
>>>>
>>>> I just reviewed Alexandre's new binding, and it makes the whole thing
>>>> a lot more obscure: on older SoCs, we have to chain 2 channels to
>>>> create an acceptable wraparound time (16 bits at 5MHz is generating too
>>>> much interrupts to be acceptable).
>>>>
>>>> If we don't assign the mode from the DT, how should we know which
>>>> channels should be chained to create the free-running timer? Note that
>>>> not all channels can be chained together: they have to be part of the
>>>> same timer counter block and have to be consecutive (0+1, 1+2 or 3+0).
>>>
>>> The driver can have this knowledge if it is just picking 2 consecutive
>>> timers. It should already know it has 16-bit timers based on the
>>> compatible string. If it gets more complicated then the features or
>>> limitations of the channels should be listed so the driver can make a
>>> choice. OMAP is a good example of lots of timers with differing
>>> features.
>>
>> Yes it's possible to do that, but what about DT overlays then? Say you
>> have some TCB channels you'd like to reserve because they are connected
>> to pins that are exposed on your board. Those pins are not connected to
>> any device yet, but extension boards can be added, and in this case you
>> might want to expose new PWM devices by dynamically loading DT overlays.
>>
>> If your clksource/clkevent driver parsed the initial DT and picked X
>> free channels randomly, it may conflicts with the one requested by the
>> DT overlay.
>>
>> What's your solution for this case?
>
> It seems that we don't have any progress on this topic for more than 6
> months which is a pity as we now experience an issue that would have
> been addressed completely by the TC rework [1].
>
> aka "ping"... ;-)


Hi Nicolas, Boris,

is there any news from your side ?

Thanks.

-- Daniel


--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

\
 
 \ /
  Last update: 2017-04-07 14:15    [W:0.135 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site