Hi Ashwin.
On 09/07/15 13:25, Ashwin Chaugule wrote:
Hi Sudeep,
On 9 July 2015 at 05:06, Sudeep Holla sudeep.holla@arm.com wrote:
Hi,
On 08/07/15 21:28, Ashwin Chaugule wrote:
On 8 July 2015 at 16:05, Ashwin Chaugule ashwin.chaugule@linaro.org wrote:
On 8 July 2015 at 15:55, Rafael J. Wysocki rafael@kernel.org wrote:
Perhaps the confusion is coming from the introduction of ACPI_CST in this file. I could leave it as it is and just separate out the ACPI_PSS bits. But I figured, while I'm at it, I'd introduce ACPI_CST, since we know the LPI stuff is coming up soon as a CST alternative anyway. So if you prefer, I can drop the CST bits and maybe Sudeep can address that as part of his LPI patchset?
Correct, I will handle it as a prerequisite for introducing _LPI support. I had posted an RFC long back, will revive those patches and repost them soon.
It's better to enable ACPI_PROCESSOR on ARM64 only after we have all these dependencies resolved. Until then we need to carry some patches locally for testing.
With Rafaels latest suggestion of adding ACPI_PROCESSOR_IDLE, we dont need to wait until all dependencies are resolved to enable acpi_processor on ARM64. CPPC patchwork has been up for review for quite a long time and has been validated on hardware. There is no reason for it to be blocked until LPI is upstream ready.
Agreed, by the way I didn't mean to block CPPC work. It can be merged when/if it's ready irrespective of _LPI support, what I meant is to enable ACPI_PROCESSOR on ARM64 when other dependencies are resolved rather than introducing just build fixes for time-being.
I think we still have one dependency for hotplug. I don't like the weak definitions introduced, but don't have a better solution either.
Regards, Sudeep