On Tue, Mar 21, 2017 at 07:47:11PM +0800, Leo Yan wrote: > On Tue, Mar 21, 2017 at 10:16:45AM +0000, Suzuki K Poulose wrote: > > [...] > > > >>In my opinion booting with "nohlt" on the cmd line is sufficient to > > >>determine if we should use the driver or not. That way we also avoid > > >>declaring yet another sysfs flag, something I really want to avoid. > > > > > >Agree. > > > > > >I did spend some time to implement coresight core framework to support > > >debug module, you could see it on:http://termbin.com/k2fj; this also > > >gives me more sense which is better choice. If declaring another sysfs > > >flag to support debug module in coresight framework, this lets the > > >codes and interfaces more complex. E.g. for best fit into coresight > > >framework, finally we can get 8 sysfs nodes for 8 CPUs in system; so > > >that means we need enable every CPU one by one. > > > > Having a node for each debug area indeed doesn't look good. We could > > as will stick a single node under /sys/kernel/debug/ which would enable/disable > > the debug component. > > > > I am OK with it being tied to nohlt. In that case we will have to add > > a Kconfig dependency on GENERIC_IDLE_POLL_SETUP (though it is selected > > by default on ARM/ARM64). Parsing the boot command line for nohlt doesn't > > look like a good idea. We may have to figure out a way to do that. > > I remembered that we can use QoS constraint for CPUIdle: > pm_qos_add_request(pm_qos_req, PM_QOS_CPU_DMA_LATENCY, 0); > > Using this way we can disable all low power states and don't depend on > nohlt anymore. The idea is to use "nohlt" as a trigger option. If it is set then we use this driver - if it isn't then it is kept under wrap. > > > Also, please could you add support for building this as a module ? Since it > > doesn't depend on the coresight bus anyway, it should be pretty straight > > forward. > > Yeah. Will support module building. > > Thanks, > Leo Yan -- 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
