On Fri, May 15, 2015 at 02:45:28PM +0200, Mason wrote: > The sad part is: I'm working on the "new" kernel. > The current "official" kernel is 3.4 (and I'm afraid > there's a 2.6.32 still kicking around somewhere). > > I'm trying to convince management that one of the advantages > of mainlining the port is that it is easier to switch to newer > kernels. Do you agree with this assertion? Yes and no. If you can get stuff upstream, it should make things easier. The difficult bit - and time consuming bit - is getting code upstream. Even in my position, I'd suggest allowing about five years for that activity, and even then don't have expectations of getting everything upstream. Frankly now, my advice to people would be to just not bother, it's *way* too much effort to get everything to an acceptable state, especially if the SoC has no support what so ever. For example, we're still banging on over the iMX6 SoCs - just getting the display stuff sorted took more than a year. Ethernet keeps becoming unstable (people keep reporting problems with it) and it became far too difficult for me to get my patch set for that upstream, so I dumped it. > > I think you'll have to do the research for that yourself... what > > I can say is that TWD is capable of one-shot mode, > > Is one-shot mode preferred over periodic mode? > (Seems counter-intuitive, as one-shot mode needs to be > periodically reprogrammed, whereas periodic mode just > keeps firing.) Think about it in terms of high-resolution timers. How can something that's programmed to fire HZ times a second provide you with a high resolution timer? Something that you can program for an arbitary period depending on your needs obviously allows higher resolution intervals, up to the minimum timer count interval. It can also provide a longer interval, up to the maximum timer count interval. > > and is capable of running as a high-res timer: > > > > Per CPU device: 0 > > Clock Event Device: local_timer > > max_delta_ns: 21691754031 > > min_delta_ns: 1000 > > mult: 425201762 > > shift: 31 > > mode: 3 <== CLOCK_EVT_MODE_ONESHOT > > next_event: 595603944000000 nsecs > > set_next_event: twd_set_next_event > > set_mode: twd_set_mode > > event_handler: hrtimer_interrupt <== indicates that it's switched > > to high-res mode > > retries: 0 > > I'm confused. > > In the "High-resolution timers not supported when using > smp_twd on Cortex A9" thread, you seemed to agree that > TWD could not be used as a hrtimer... I guess I was wrong. I'm no expert on the kernel's time code. That's why I've suggested to you several times that you do the research yourself, rather than me having to do that research for you and then write an email about it. It's kind of wasting my time, and you're not paying me for this kind of support service... > > Yes - because the TWD stops in low power modes, which makes it > > unsuitable as a high-resolution timer. These kinds of issues > > are annoying, but it's the way things are. > > So it looks like TWD can be used as a hrtimer, but something > on my platform is making it choose otherwise, and it is not > the CLOCK_EVT_FEAT_C3STOP flag? I've no idea. I don't have the 3.14 code in front of me to research. I _could_ wind my tree back to 3.14, and read that code, but I don't see why I should go to all that effort... especially as I have other things I need to be getting on with, and other problems to be taking care of. What I'm saying is that I have a platform here running a modern kernel which _does_ use the TWD, and it _does_ appear to be running in high-res mode. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
