On Tue, Sep 10, 2019 at 02:51:50PM +0000, Claudiu.Beznea@xxxxxxxxxxxxx wrote: > > > On 10.09.2019 17:32, Sudeep Holla wrote: > > External E-Mail > > > > > > On Tue, Sep 10, 2019 at 04:47:13PM +0300, Claudiu Beznea wrote: > >> From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> > >> > >> Some timer drivers may behave either as clocksource or clockevent > >> or both. Until now, in case of platforms with multiple hardware > >> resources of the same type, the drivers were chosing the first > >> registered hardware resource as clocksource/clockevent and the > >> next one as clockevent/clocksource. Other were using different > >> compatibles (one for each functionality, although its about the > >> same hardware). Add DT bindings to be able to choose the > >> functionality of a timer. > >> > > > > Is the piece of hardware not capable of serving as both clocksource > > and clockevent or is it just the platform choice ? > > In my case, the hardware is not capable of serving at the same time > a clocksource device and a clockevent device. > > First, I published v1 for a hardware device having this behavior at > [1] requesting 1st probed hardware device to work as clocksource and > the 2nd one to work as clockevent. The discussion at [1] ended up with > the idea of having a mechanism to specify which hardware device behaves > as clocksource and which one behaves as clockevent. > 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. -- Regards, Sudeep _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
