On Thu, Nov 05, 2020 at 12:36:21PM +0000, Jonathan Cameron via Linaro-open-discussions wrote:
Hi all,
This is a fusion of Mike's notes and my own. Please add anything I missed! People may well be misidentified (sorry about that). Was very good active discussion. Thanks to all involved and Mike in particular for organizing it and taking live notes.
General request
- Slides for all topics next time to introduce topics as not everyone on call will have necessary background (and those that do might need reminding!) Hanjun is sending Mike his slides (uncore DVFS) to add to the collaborate page.
IORT - Reserve memory regions (RMR)
- Shameer gave summary
- IORT Revision E (https://developer.arm.com/documentation/den0049/latest/) introduced new node type.
- A way to describe memory regions that should have unity mapping in the SMMU.
- Use case is a PCIe RAID card that has FW that uses a pool of host memory (hidden from OS).
- Status
- Patches out for ACPICA
- Question raised by ACPICA reviewers on whether spec is final
- Spec appears final (Lorenzo to check) but may be minor unrelated fix in doc to come (Sami).
- Patches out for kernel on relevant lists.
- Mail from Steven Price (Arm) - (Sami Mujawar who was on the call also involved) interested for EFI framebuffer use case.
- Open questions
- Equivalent from AMD has flag to indicate that unity mapping only needed until driver has taken over (end of kernel boot assumed). Avoids and issue of holes in address space for VMs.
- Huawei not raising this as a requirement, but Lorenzo observed interesting and deserves discussion.
- Kexec interaction needs discussions. Steve looking at this an will bring to list.
- Lorenzo brought up issue of IORT spec using PCI BDF (stream ID?) which may be reenumerated.
- Noted x86 doesn't do this but ARM traditionally does.
- There is a DSM that tells the kernel not to reenumerate the PCI bus which ACPI obeys.
- Jonathan suggestion was potentially opportunity to cache original stream ID before doing the reenumeration in kernel.
- Lorenzo observed we may need a universal solution for all OSes on this. Lorenzo took AI to go away and think about it before next call.
- Stalling issues on patch? Probably only Kexec though should be careful around possible future regressions on the BDF issue (not a blocker)
- Related DT story. Huawei server team not interested as no DT support and can't test. Lorenzo suggested looping in Thierry Reding and reference a patch set (probably https://lore.kernel.org/linux-iommu/20200904130000.691933-1-thierry.reding@g...) Huawei more than happy to have others add the DT support :)
AI summary:
- Kexec discussion - on list.
- Use of BDF discussion - revisit here next time.
I have an update on this topic and the RMR flags to free up IOVA.
Is December 2nd confirmed as next session ? If possible 3PM GMT works better for me; the NUMA topic raised by Jonathan is another interesting topic for debate. Other than that we can slot in the topics that weren't discussed last time:
https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
even though those require a bit of preparation so the sooner we finalize the schedule the better.
Please let me know, thanks.
Lorenzo
- DT alignment. Don't want different solutions for each firmware type.
- Lorenzo / Sami to check IORT revision E is final.
SVA
Zangfei gave summary:
- Huawei has devices that are not PCIe but are presented as such.
- They support stall mode for SVA (spec violation)
- Resistance from kernel maintainers to maintaining a white list for any quirk. Fine to fix it once (JPB), but not to keep doing so.
- Note that stall mode not yet supported at all (JPB to send out this cycle).
- If longer term fix need add can't be done via PCISIG etc then need to convince PCI and SMMU maintainers. Noted that quirk is very little code.
- Other SVA topics.
- Mentioned virtual SVA (no actually problems just expressing interest!)
- Would need Eric Auger, wasn't on topic list so Eric not on call.
AI: Nothing planned until after JPB has upstreamed stall mode. Hard to have discussion before that.
DVFS
guohanjun
Solutions exist for
- CPU DVFS (voltage + frequency scaling)
- PCIe device power states etc
No standard way of controlling Uncore voltage and frequency for ACPI based systems.
3 options:
- MMIO / kernel driver.
- PSCI via trusted firmware and system management controller.
- ACPI (wrapping up an op region and SCMI)
Clarifications / discussions.
- Vincent G: Power states, or voltage frequency of interest? Ans Voltage Freq
- Considered SCMI? Ans: Works only for DT as SCMI under ACPI is wrapped up in AML so looks like an ACPI interface.
- Sudeep H: Necessary to trace CPU freq? Yes.
- Sudeep H: Why not do it in firmware entirely? Ans. Not just CPU. For example PCI device accessing memory may well need the ring bus to be fast.
- Vincent G: Bandwidth affected? Yes. VG: mobile does this by specifying a BW requirement (via SCMI.-
- Sudeep H Observed need to expose it via ACPI spec. (option 3 above).
- Sudeep H: Does PCI also need fine-grain control? We might need to add to the spec.
- Sudeep H: What are the requirements? gaohanjun: Now we just frequency scaling.
- Jonathan C: Noted PCI power state is not enough. It's workload dependent.
- Sudeep H: We need to gather all the info, need to talk in ASWG about DVFS
- Jonathan C: For now direct control probably makes sense. Whilst it would be nice to have a detailed enough system description in a standard way to make general software that is a big spec job.
- Jonathan C: Seems like true standard SW will not happen any time soon.
AI: RFC to the linux-pm / linux-acpi Rafael and those in this discussion to ask about interest in adding per device DVFS to ACPI spec. Possibly pursue code first ACPI approach.
If I've miss listed or "volunteered" anyone for AIs they didn't agree to then please correct that.
Thanks all for contributions. I for one found it a very useful call!
Jonathan
-- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions
On Mon, 23 Nov 2020 15:12:53 +0000 Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
On Thu, Nov 05, 2020 at 12:36:21PM +0000, Jonathan Cameron via Linaro-open-discussions wrote:
Hi all,
This is a fusion of Mike's notes and my own. Please add anything I missed! People may well be misidentified (sorry about that). Was very good active discussion. Thanks to all involved and Mike in particular for organizing it and taking live notes.
General request
- Slides for all topics next time to introduce topics as not everyone on call will have necessary background (and those that do might need reminding!) Hanjun is sending Mike his slides (uncore DVFS) to add to the collaborate page.
IORT - Reserve memory regions (RMR)
- Shameer gave summary
- IORT Revision E (https://developer.arm.com/documentation/den0049/latest/) introduced new node type.
- A way to describe memory regions that should have unity mapping in the SMMU.
- Use case is a PCIe RAID card that has FW that uses a pool of host memory (hidden from OS).
- Status
- Patches out for ACPICA
- Question raised by ACPICA reviewers on whether spec is final
- Spec appears final (Lorenzo to check) but may be minor unrelated fix in doc to come (Sami).
- Patches out for kernel on relevant lists.
- Mail from Steven Price (Arm) - (Sami Mujawar who was on the call also involved) interested for EFI framebuffer use case.
- Open questions
- Equivalent from AMD has flag to indicate that unity mapping only needed until driver has taken over (end of kernel boot assumed). Avoids and issue of holes in address space for VMs.
- Huawei not raising this as a requirement, but Lorenzo observed interesting and deserves discussion.
- Kexec interaction needs discussions. Steve looking at this an will bring to list.
- Lorenzo brought up issue of IORT spec using PCI BDF (stream ID?) which may be reenumerated.
- Noted x86 doesn't do this but ARM traditionally does.
- There is a DSM that tells the kernel not to reenumerate the PCI bus which ACPI obeys.
- Jonathan suggestion was potentially opportunity to cache original stream ID before doing the reenumeration in kernel.
- Lorenzo observed we may need a universal solution for all OSes on this. Lorenzo took AI to go away and think about it before next call.
- Stalling issues on patch? Probably only Kexec though should be careful around possible future regressions on the BDF issue (not a blocker)
- Related DT story. Huawei server team not interested as no DT support and can't test. Lorenzo suggested looping in Thierry Reding and reference a patch set (probably https://lore.kernel.org/linux-iommu/20200904130000.691933-1-thierry.reding@g...) Huawei more than happy to have others add the DT support :)
AI summary:
- Kexec discussion - on list.
- Use of BDF discussion - revisit here next time.
Hi Lorenzo, Mike,
I have an update on this topic and the RMR flags to free up IOVA.
Great, Mike - can you add those to the agenda on collaborate so we keep track.
Is December 2nd confirmed as next session ? If possible 3PM GMT works better for me; the NUMA topic raised by Jonathan is another interesting topic for debate.
Just to check, which NUMA topic? I've lost track of what we are talking about.
Other than that we can slot in the topics that weren't discussed last time:
https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
even though those require a bit of preparation so the sooner we finalize the schedule the better.
Seems we have clashed with some internal Huawei activities so some people who would normally be active are snowed under this week.
Jonathan
Please let me know, thanks.
Lorenzo
- DT alignment. Don't want different solutions for each firmware type.
- Lorenzo / Sami to check IORT revision E is final.
SVA
Zangfei gave summary:
- Huawei has devices that are not PCIe but are presented as such.
- They support stall mode for SVA (spec violation)
- Resistance from kernel maintainers to maintaining a white list for any quirk. Fine to fix it once (JPB), but not to keep doing so.
- Note that stall mode not yet supported at all (JPB to send out this cycle).
- If longer term fix need add can't be done via PCISIG etc then need to convince PCI and SMMU maintainers. Noted that quirk is very little code.
- Other SVA topics.
- Mentioned virtual SVA (no actually problems just expressing interest!)
- Would need Eric Auger, wasn't on topic list so Eric not on call.
AI: Nothing planned until after JPB has upstreamed stall mode. Hard to have discussion before that.
DVFS
guohanjun
Solutions exist for
- CPU DVFS (voltage + frequency scaling)
- PCIe device power states etc
No standard way of controlling Uncore voltage and frequency for ACPI based systems.
3 options:
- MMIO / kernel driver.
- PSCI via trusted firmware and system management controller.
- ACPI (wrapping up an op region and SCMI)
Clarifications / discussions.
- Vincent G: Power states, or voltage frequency of interest? Ans Voltage Freq
- Considered SCMI? Ans: Works only for DT as SCMI under ACPI is wrapped up in AML so looks like an ACPI interface.
- Sudeep H: Necessary to trace CPU freq? Yes.
- Sudeep H: Why not do it in firmware entirely? Ans. Not just CPU. For example PCI device accessing memory may well need the ring bus to be fast.
- Vincent G: Bandwidth affected? Yes. VG: mobile does this by specifying a BW requirement (via SCMI.-
- Sudeep H Observed need to expose it via ACPI spec. (option 3 above).
- Sudeep H: Does PCI also need fine-grain control? We might need to add to the spec.
- Sudeep H: What are the requirements? gaohanjun: Now we just frequency scaling.
- Jonathan C: Noted PCI power state is not enough. It's workload dependent.
- Sudeep H: We need to gather all the info, need to talk in ASWG about DVFS
- Jonathan C: For now direct control probably makes sense. Whilst it would be nice to have a detailed enough system description in a standard way to make general software that is a big spec job.
- Jonathan C: Seems like true standard SW will not happen any time soon.
AI: RFC to the linux-pm / linux-acpi Rafael and those in this discussion to ask about interest in adding per device DVFS to ACPI spec. Possibly pursue code first ACPI approach.
If I've miss listed or "volunteered" anyone for AIs they didn't agree to then please correct that.
Thanks all for contributions. I for one found it a very useful call!
Jonathan
-- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions
On Wed, Nov 25, 2020 at 12:51:49PM +0000, Jonathan Cameron wrote:
[...]
Is December 2nd confirmed as next session ? If possible 3PM GMT works better for me; the NUMA topic raised by Jonathan is another interesting topic for debate.
Just to check, which NUMA topic?
https://op-lists.linaro.org/pipermail/linaro-open-discussions/2020-November/...
It would be useful (for me certainly) if you can give an update on what's still pending in the items in the discussion above (eg it is not clear what the "PCI fix" is) + how it is linked to CXL.
The vCPU hotplug is also worth adding (even though I do not know what was discussed at KVM forum).
Furthermore, I am keen on discussing this:
https://lore.kernel.org/linux-arm-kernel/20201123065410.1915-1-lushenming@hu...
if the submitters are available, it would help to get some context in relation to upstream discussions.
Thanks ! Lorenzo
I've lost track of what we are talking about.
Other than that we can slot in the topics that weren't discussed last time:
https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
even though those require a bit of preparation so the sooner we finalize the schedule the better.
Seems we have clashed with some internal Huawei activities so some people who would normally be active are snowed under this week.
Jonathan
Please let me know, thanks.
Lorenzo
- DT alignment. Don't want different solutions for each firmware type.
- Lorenzo / Sami to check IORT revision E is final.
SVA
Zangfei gave summary:
- Huawei has devices that are not PCIe but are presented as such.
- They support stall mode for SVA (spec violation)
- Resistance from kernel maintainers to maintaining a white list for any quirk. Fine to fix it once (JPB), but not to keep doing so.
- Note that stall mode not yet supported at all (JPB to send out this cycle).
- If longer term fix need add can't be done via PCISIG etc then need to convince PCI and SMMU maintainers. Noted that quirk is very little code.
- Other SVA topics.
- Mentioned virtual SVA (no actually problems just expressing interest!)
- Would need Eric Auger, wasn't on topic list so Eric not on call.
AI: Nothing planned until after JPB has upstreamed stall mode. Hard to have discussion before that.
DVFS
guohanjun
Solutions exist for
- CPU DVFS (voltage + frequency scaling)
- PCIe device power states etc
No standard way of controlling Uncore voltage and frequency for ACPI based systems.
3 options:
- MMIO / kernel driver.
- PSCI via trusted firmware and system management controller.
- ACPI (wrapping up an op region and SCMI)
Clarifications / discussions.
- Vincent G: Power states, or voltage frequency of interest? Ans Voltage Freq
- Considered SCMI? Ans: Works only for DT as SCMI under ACPI is wrapped up in AML so looks like an ACPI interface.
- Sudeep H: Necessary to trace CPU freq? Yes.
- Sudeep H: Why not do it in firmware entirely? Ans. Not just CPU. For example PCI device accessing memory may well need the ring bus to be fast.
- Vincent G: Bandwidth affected? Yes. VG: mobile does this by specifying a BW requirement (via SCMI.-
- Sudeep H Observed need to expose it via ACPI spec. (option 3 above).
- Sudeep H: Does PCI also need fine-grain control? We might need to add to the spec.
- Sudeep H: What are the requirements? gaohanjun: Now we just frequency scaling.
- Jonathan C: Noted PCI power state is not enough. It's workload dependent.
- Sudeep H: We need to gather all the info, need to talk in ASWG about DVFS
- Jonathan C: For now direct control probably makes sense. Whilst it would be nice to have a detailed enough system description in a standard way to make general software that is a big spec job.
- Jonathan C: Seems like true standard SW will not happen any time soon.
AI: RFC to the linux-pm / linux-acpi Rafael and those in this discussion to ask about interest in adding per device DVFS to ACPI spec. Possibly pursue code first ACPI approach.
If I've miss listed or "volunteered" anyone for AIs they didn't agree to then please correct that.
Thanks all for contributions. I for one found it a very useful call!
Jonathan
-- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions
On Wed, 25 Nov 2020 13:58:38 +0000 Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
On Wed, Nov 25, 2020 at 12:51:49PM +0000, Jonathan Cameron wrote:
[...]
Is December 2nd confirmed as next session ? If possible 3PM GMT works better for me; the NUMA topic raised by Jonathan is another interesting topic for debate.
Just to check, which NUMA topic?
https://op-lists.linaro.org/pipermail/linaro-open-discussions/2020-November/...
It would be useful (for me certainly) if you can give an update on what's still pending in the items in the discussion above (eg it is not clear what the "PCI fix" is) + how it is linked to CXL.
Sure, that should be a fairly short topic, but I'm happy to try to fill in the gaps. @Mike, can you add "Generic initiators - pending items" to the agenda.
For the PCI 'fix' it is this one that got applied and then reverted in 4.20 timeframe http://patchwork.ozlabs.org/project/linux-pci/patch/20180912152140.3676-2-Jo... I've not rebased or tested it recently so I'll check that it still appears to be right before the call.
The vCPU hotplug is also worth adding (even though I do not know what was discussed at KVM forum).
I was just about to email about that one. From our side, all that is currently going on around vCPU Hotplug is a rebase. At KVM forum Mark R kindly offered to see if he could find out answers to a few open questions. Perhaps catch up with Mark, or see if he can make the call?
Furthermore, I am keen on discussing this:
https://lore.kernel.org/linux-arm-kernel/20201123065410.1915-1-lushenming@hu...
if the submitters are available, it would help to get some context in relation to upstream discussions.
I've messaged lushenming so hopefully we can sort out something on that front.
Looks like finding a time next week is proving challenging. If that fails, perhaps we should try for the week after?
Thanks,
Jonathan
Thanks ! Lorenzo
I've lost track of what we are talking about.
Other than that we can slot in the topics that weren't discussed last time:
https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
even though those require a bit of preparation so the sooner we finalize the schedule the better.
Seems we have clashed with some internal Huawei activities so some people who would normally be active are snowed under this week.
Jonathan
Please let me know, thanks.
Lorenzo
- DT alignment. Don't want different solutions for each firmware type.
- Lorenzo / Sami to check IORT revision E is final.
SVA
Zangfei gave summary:
- Huawei has devices that are not PCIe but are presented as such.
- They support stall mode for SVA (spec violation)
- Resistance from kernel maintainers to maintaining a white list for any quirk. Fine to fix it once (JPB), but not to keep doing so.
- Note that stall mode not yet supported at all (JPB to send out this cycle).
- If longer term fix need add can't be done via PCISIG etc then need to convince PCI and SMMU maintainers. Noted that quirk is very little code.
- Other SVA topics.
- Mentioned virtual SVA (no actually problems just expressing interest!)
- Would need Eric Auger, wasn't on topic list so Eric not on call.
AI: Nothing planned until after JPB has upstreamed stall mode. Hard to have discussion before that.
DVFS
guohanjun
Solutions exist for
- CPU DVFS (voltage + frequency scaling)
- PCIe device power states etc
No standard way of controlling Uncore voltage and frequency for ACPI based systems.
3 options:
- MMIO / kernel driver.
- PSCI via trusted firmware and system management controller.
- ACPI (wrapping up an op region and SCMI)
Clarifications / discussions.
- Vincent G: Power states, or voltage frequency of interest? Ans Voltage Freq
- Considered SCMI? Ans: Works only for DT as SCMI under ACPI is wrapped up in AML so looks like an ACPI interface.
- Sudeep H: Necessary to trace CPU freq? Yes.
- Sudeep H: Why not do it in firmware entirely? Ans. Not just CPU. For example PCI device accessing memory may well need the ring bus to be fast.
- Vincent G: Bandwidth affected? Yes. VG: mobile does this by specifying a BW requirement (via SCMI.-
- Sudeep H Observed need to expose it via ACPI spec. (option 3 above).
- Sudeep H: Does PCI also need fine-grain control? We might need to add to the spec.
- Sudeep H: What are the requirements? gaohanjun: Now we just frequency scaling.
- Jonathan C: Noted PCI power state is not enough. It's workload dependent.
- Sudeep H: We need to gather all the info, need to talk in ASWG about DVFS
- Jonathan C: For now direct control probably makes sense. Whilst it would be nice to have a detailed enough system description in a standard way to make general software that is a big spec job.
- Jonathan C: Seems like true standard SW will not happen any time soon.
AI: RFC to the linux-pm / linux-acpi Rafael and those in this discussion to ask about interest in adding per device DVFS to ACPI spec. Possibly pursue code first ACPI approach.
If I've miss listed or "volunteered" anyone for AIs they didn't agree to then please correct that.
Thanks all for contributions. I for one found it a very useful call!
Jonathan
-- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions
On Wed, Nov 25, 2020 at 03:22:19PM +0000, Jonathan Cameron wrote:
On Wed, 25 Nov 2020 13:58:38 +0000 Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
On Wed, Nov 25, 2020 at 12:51:49PM +0000, Jonathan Cameron wrote:
[...]
Is December 2nd confirmed as next session ? If possible 3PM GMT works better for me; the NUMA topic raised by Jonathan is another interesting topic for debate.
Just to check, which NUMA topic?
https://op-lists.linaro.org/pipermail/linaro-open-discussions/2020-November/...
It would be useful (for me certainly) if you can give an update on what's still pending in the items in the discussion above (eg it is not clear what the "PCI fix" is) + how it is linked to CXL.
Sure, that should be a fairly short topic, but I'm happy to try to fill in the gaps. @Mike, can you add "Generic initiators - pending items" to the agenda.
For the PCI 'fix' it is this one that got applied and then reverted in 4.20 timeframe http://patchwork.ozlabs.org/project/linux-pci/patch/20180912152140.3676-2-Jo... I've not rebased or tested it recently so I'll check that it still appears to be right before the call.
The vCPU hotplug is also worth adding (even though I do not know what was discussed at KVM forum).
I was just about to email about that one. From our side, all that is currently going on around vCPU Hotplug is a rebase. At KVM forum Mark R kindly offered to see if he could find out answers to a few open questions. Perhaps catch up with Mark, or see if he can make the call?
Ok, will catch up with him, it is probably better if I have some time to do it (ie postpone the call for a week).
Furthermore, I am keen on discussing this:
https://lore.kernel.org/linux-arm-kernel/20201123065410.1915-1-lushenming@hu...
if the submitters are available, it would help to get some context in relation to upstream discussions.
I've messaged lushenming so hopefully we can sort out something on that front.
Looks like finding a time next week is proving challenging. If that fails, perhaps we should try for the week after?
Yes we can, it would be easier to prepare the topics and find a suitable day as well, next week it looks like it is challenging. It would also give us some time to extend the invite.
Please let me know and apologies to Mike for all these emails to get it organized.
Thanks, Lorenzo
Thanks,
Jonathan
Thanks ! Lorenzo
I've lost track of what we are talking about.
Other than that we can slot in the topics that weren't discussed last time:
https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
even though those require a bit of preparation so the sooner we finalize the schedule the better.
Seems we have clashed with some internal Huawei activities so some people who would normally be active are snowed under this week.
Jonathan
Please let me know, thanks.
Lorenzo
- DT alignment. Don't want different solutions for each firmware type.
- Lorenzo / Sami to check IORT revision E is final.
SVA
Zangfei gave summary:
- Huawei has devices that are not PCIe but are presented as such.
- They support stall mode for SVA (spec violation)
- Resistance from kernel maintainers to maintaining a white list for any quirk. Fine to fix it once (JPB), but not to keep doing so.
- Note that stall mode not yet supported at all (JPB to send out this cycle).
- If longer term fix need add can't be done via PCISIG etc then need to convince PCI and SMMU maintainers. Noted that quirk is very little code.
- Other SVA topics.
- Mentioned virtual SVA (no actually problems just expressing interest!)
- Would need Eric Auger, wasn't on topic list so Eric not on call.
AI: Nothing planned until after JPB has upstreamed stall mode. Hard to have discussion before that.
DVFS
guohanjun
Solutions exist for
- CPU DVFS (voltage + frequency scaling)
- PCIe device power states etc
No standard way of controlling Uncore voltage and frequency for ACPI based systems.
3 options:
- MMIO / kernel driver.
- PSCI via trusted firmware and system management controller.
- ACPI (wrapping up an op region and SCMI)
Clarifications / discussions.
- Vincent G: Power states, or voltage frequency of interest? Ans Voltage Freq
- Considered SCMI? Ans: Works only for DT as SCMI under ACPI is wrapped up in AML so looks like an ACPI interface.
- Sudeep H: Necessary to trace CPU freq? Yes.
- Sudeep H: Why not do it in firmware entirely? Ans. Not just CPU. For example PCI device accessing memory may well need the ring bus to be fast.
- Vincent G: Bandwidth affected? Yes. VG: mobile does this by specifying a BW requirement (via SCMI.-
- Sudeep H Observed need to expose it via ACPI spec. (option 3 above).
- Sudeep H: Does PCI also need fine-grain control? We might need to add to the spec.
- Sudeep H: What are the requirements? gaohanjun: Now we just frequency scaling.
- Jonathan C: Noted PCI power state is not enough. It's workload dependent.
- Sudeep H: We need to gather all the info, need to talk in ASWG about DVFS
- Jonathan C: For now direct control probably makes sense. Whilst it would be nice to have a detailed enough system description in a standard way to make general software that is a big spec job.
- Jonathan C: Seems like true standard SW will not happen any time soon.
AI: RFC to the linux-pm / linux-acpi Rafael and those in this discussion to ask about interest in adding per device DVFS to ACPI spec. Possibly pursue code first ACPI approach.
If I've miss listed or "volunteered" anyone for AIs they didn't agree to then please correct that.
Thanks all for contributions. I for one found it a very useful call!
Jonathan
-- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions
linaro-open-discussions@op-lists.linaro.org
-
Jonathan Cameron -
Lorenzo Pieralisi