On Tue, 2016-09-20 at 10:35 +0100, Mark Rutland wrote: > On Mon, Sep 19, 2016 at 02:16:00PM -0500, Scott Wood wrote: > > > > On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote: > > > > > > > > > > > > > > > > > Reconsidering my suggestion, I realise this will also affect the > > > > > MMIO > > > > > timers, so that doesn't work. > > > > > > > > > > So for the moment, I guess we have to keep > > > > > fsl_a008585_set_next_event(). > > > > What is the problem with MMIO timers? needs_fsl_a008585_workaround() > > > > should > > > > always be false for them. > > > As suggested, needs_fsl_a008585_workaround() takes no parameter, and > > > set_next_event is called for both cp15/sysreg and MMIO timers. So it > > > would either be true for all, or false for all. > > > > > > If it's true for all, we'd end up calling fsl_a008585_set_next_event() > > > for the MMIO timers too. > > There should not be any MMIO timers on a system where > > fsl_a008585_set_next_event() returns true. > I'm generally not keen on relying on that. > > For reference, are no MMIO timers implemented at all, or are they simply > not listed in the DT today? As far as I can tell they're not implemented, but it's possible I'm just not looking at the right documentation. I agree though that depending on that isn't particularly pretty. I'll stick with the current approach for set_next_event(). -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
