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.
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
