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]).
Thank you,
Claudiu Beznea
[1]
https://lore.kernel.org/lkml/1552580772-8499-1-git-send-email-claudiu.beznea@xxxxxxxxxxxxx/
[2]
https://lore.kernel.org/lkml/a738fce5-1108-34d7-d255-dfcb86f51c56@xxxxxxxxxx/
[3]
https://lore.kernel.org/lkml/2f831f1b-c87d-48bd-cf02-2ebb334b964c@xxxxxxxxxx/
> Clocksource and clockevent are natural singletons so there is
> no need to handle more than one of each in a driver for identical
> hardware.
>
> With the Integrator AP timer there is a real reason to select one over
> the other but as I replied to that patch it is pretty easy to just identify
> which block has this limitation by simply commenting out the IRQ
> line for it from the device tree.
>
> Maybe there is something about this I don't understand.
>
> Yours,
> Linus Walleij
>
_______________________________________________
linux-unisoc mailing list
linux-unisoc@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-unisoc
