Hi Ashwin.
On 09/07/15 13:25, Ashwin Chaugule wrote:
Hi Sudeep,
On 9 July 2015 at 05:06, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
Hi,
On 08/07/15 21:28, Ashwin Chaugule wrote:
On 8 July 2015 at 16:05, Ashwin Chaugule <ashwin.chaugule@xxxxxxxxxx>
wrote:
On 8 July 2015 at 15:55, Rafael J. Wysocki <rafael@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
