On 30.09.2019 17:32, Rob Herring wrote:
> On Wed, Sep 11, 2019 at 07:18:07AM +0000, Claudiu.Beznea@xxxxxxxxxxxxx wrote:
>>
>>
>> On 11.09.2019 03:03, Linus Walleij wrote:
>>> External E-Mail
>>>
>>>
>>> On Tue, Sep 10, 2019 at 4:11 PM Alexandre Belloni
>>> <alexandre.belloni@xxxxxxxxxxx> wrote:
>>>> On 10/09/2019 16:08:26+0100, Sudeep Holla wrote:
>>>>> On Tue, Sep 10, 2019 at 02:51:50PM +0000, Claudiu.Beznea@xxxxxxxxxxxxx wrote:
>>>
>>>>> In that case, why can't we identify capability that with the compatibles
>>>>> for this timer IP ?
>>>>>
>>>>> IOW, I don't like the proposal as it's hardware limitation.
>>>>
>>>> To be clear, bot timers are exactly the same but can't be clocksource
>>>> and clockevent at the same time. Why would we have different compatibles
>>>> for the exact same IP?
>>>
>>> In that case why not just pick the first one you find as clocksource
>>> and the second one as clock event? As they all come to the
>>> same timer of init function two simple local state variables can
>>> solve that:
>>>
>>> static bool registered_clocksource;
>>> static bool registered_clockevent;
>>>
>>> probe(timer) {
>>> if (!registered_clocksource) {
>>> register_clocksource(timer);
>>> registrered_clocksource = true;
>>> return;
>>> }
>>> if (!registered_clockevent) {
>>> register_clockevent(timer);
>>> registered_clockevent = true;
>>> return;
>>> }
>>> pr_info("surplus timer %p\n", timer);
>>> }
>>>
>>
>> That was also my proposal for the driver I'm sending this series for (see
>> [1]) but it has been proposed to implement a mechanism similar to this one
>> in this series (see [2] and [3]).
>
> This comes up over and over, and the answer is still no. Either each
> block is identical and doesn't matter which one is used for what or
> there is some h/w difference that you should describe.
There are no hardware differences in my case. The block just cannot work at
the same time as clocksource and clockevent. And on SAM9X60's we want to
use it as clockevent for high resolution timers support.
>
> If you want something that would even be considered to put into DT,
> then define something BSD or other OS's could use too. (That's not a
> suggestion to respin this with generalized names.)
>
> Rob
>
>
_______________________________________________
linux-unisoc mailing list
linux-unisoc@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-unisoc
