- Linaro-open-discussions - op-lists.linaro.org

Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting 4 Nov 2020

by Mike Holmes

On Wed, Nov 25, 2020 at 4:01 PM Lorenzo Pieralisi via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> wrote: > 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(a)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-J… > > 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@h… > > > > > > 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. > No problem, as soon as it is confirmed we want to try for the following week I can set up a poll to pick the day and hour > > 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: > > > > > > 1. MMIO / kernel driver. > > > > > > 2. PSCI via trusted firmware and system management controller. > > > > > > 3. 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 mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions > -- Mike Holmes | Director, Foundation Technologies, Linaro Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org> "Work should be fun and collaborative, the rest follows"

4 years, 7 months

3
4
0 0

Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting 4 Nov 2020

by Mike Holmes

On Thu, Nov 26, 2020 at 8:47 AM Jonathan Cameron < jonathan.cameron(a)huawei.com> wrote: > Hi Mike, > > > > lushenming is happy to present / discuss the topic Lorenzo requested. > > > > > https://lore.kernel.org/linux-arm-kernel/20201123065410.1915-1-lushenming@h… > > > For agenda list please add “VLPI Migration support on Gic V4.1” > > > > Lorenzo also mentioned he had an update on > > “Use of BDF to identify PCI devices in ACPI tables” > > which I’d definitely like to be on the agenda. > > > > Final topic that has been discussed for inclusion is > > “vCPU hotplug” > > Let’s move that up to confirmed topics. > > > > It’s going to be a full agenda, so I suggest we try to share slides in > advance and we keep > > to a fairly tight schedule! > > > > For those doing slides, I assume best approach is email them to you Mike > and you upload > > them to the collaborate page? Perhaps if people could also let Mike know > expected time > > needed (always a guess) then we can decide to spill some topics to a > future meeting or > > email discussion if necessary. > Perfect, I will add the topics and slides > > > Thanks, > > > > Jonathan > > > > > > *From:* Mike Holmes [mailto:mike.holmes@linaro.org] > *Sent:* 26 November 2020 07:28 > *To:* Jonathan Cameron <jonathan.cameron(a)huawei.com> > *Cc:* Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>; > linaro-open-discussions(a)op-lists.linaro.org > *Subject:* Re: [Linaro-open-discussions] Notes on Linaro Open Discussions > meeting 4 Nov 2020 > > > > I see a lot of new subscriptions to the list - welcome. > > Here is the updated meeting slot poll for the week of December 7th to > December 12th > > https://doodle.com/poll/sgy9esiim4rapitz?utm_source=poll&utm_medium=link > > > > Agenda > > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > > > > > > > > On Wed, Nov 25, 2020 at 4:14 PM Jonathan Cameron < > Jonathan.Cameron(a)huawei.com> wrote: > > On Wed, 25 Nov 2020 16:05:51 +0000 > Mike Holmes <mike.holmes(a)linaro.org> wrote: > > > On Wed, Nov 25, 2020 at 4:01 PM Lorenzo Pieralisi via > > Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> > wrote: > > > > > 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(a)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-J… > > > > > 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@h… > > > > > > > > > > > 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. > > > > > > > No problem, as soon as it is confirmed we want to try for the following > > week I can set up a poll to pick the day and hour > > Definitely sounds like a better plan. Fingers crossed people have slightly > more open schedules that week! > > Thanks for sorting this out Mike. > > Jonathan > > > > > > > > > > > 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: > > > > > > > > 1. MMIO / kernel driver. > > > > > > > > 2. PSCI via trusted firmware and system management > controller. > > > > > > > > 3. 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 mailing list > > > > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > > > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions > > > > > > > > > > > > -- > > *Mike Holmes* | Director, Foundation Technologies, Linaro > > Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org> > > "Work should be fun and collaborative, the rest follows" > > > -- Mike Holmes | Director, Foundation Technologies, Linaro Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org> "Work should be fun and collaborative, the rest follows"

4 years, 7 months

1
0
0 0

Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting 4 Nov 2020

by Lorenzo Pieralisi

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@…) > 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: > 1. MMIO / kernel driver. > 2. PSCI via trusted firmware and system management controller. > 3. 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

4 years, 7 months

2
4
0 0

Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting 4 Nov 2020

by Mike Holmes

Ok we have our usual timezone problem How about one of the following? 10.00 am GMT December 3rd ? 3.00 pm GMT December 3rd ? On Tue, Nov 24, 2020 at 1:13 AM Jammy Zhou via Linaro-open-discussions < linaro-open-discussions(a)op-lists.linaro.org> wrote: > Some earlier slots can be better for potential attendees from Asia in the > early evening :-) > > Thanks, > Jammy > > On Tue, 24 Nov 2020 at 02:25, Lorenzo Pieralisi via Linaro-open-discussions > <linaro-open-discussions(a)op-lists.linaro.org> wrote: > > > On Mon, Nov 23, 2020 at 05:44:15PM +0000, Jonathan Cameron wrote: > > > > [...] > > > > > > > If possible 3PM GMT works > > > > > better for me; > > > > > > > > > > > > Linaro has a standing internal meeting with its members at 3.00 pm on > > > > December 2nd, how is 4.30 pm GMT or retain the 2.00 pm slot? > > > > > > I have another call at 4.30 but any time before that works for me. > > > If that's a problem for Lorenzo, perhaps we can shift the day slightly > > > or go earlier in the day? > > > > The only slot I can in the afternoon is 3PM to 5PM on Wednesdays. > > > > Morning it is perfectly fine but it may be too early for some people. > > > > 2PM I really can't make it I am sorry. Maybe we can try in the morning ? > > > > Please let me know, thanks a lot, > > Lorenzo > > > > > > > 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. > > > > > > > > > > > > > I think we should prepare any topic slides and have the call, does > > anyone > > > > have any additional agenda items? > > > > > > I'll chase up our end over the next few days, > > > > > > Thanks, > > > > > > Jonathan > > > > > > > > > > > > > > > > > > > > > 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: > > > > > > 1. MMIO / kernel driver. > > > > > > 2. PSCI via trusted firmware and system management controller. > > > > > > 3. 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 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 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 mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions > -- Mike Holmes | Director, Foundation Technologies, Linaro Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org> "Work should be fun and collaborative, the rest follows"

4 years, 7 months

2
2
0 0

Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting 4 Nov 2020

by Jammy Zhou

Some earlier slots can be better for potential attendees from Asia in the early evening :-) Thanks, Jammy On Tue, 24 Nov 2020 at 02:25, Lorenzo Pieralisi via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> wrote: > On Mon, Nov 23, 2020 at 05:44:15PM +0000, Jonathan Cameron wrote: > > [...] > > > > > If possible 3PM GMT works > > > > better for me; > > > > > > > > > Linaro has a standing internal meeting with its members at 3.00 pm on > > > December 2nd, how is 4.30 pm GMT or retain the 2.00 pm slot? > > > > I have another call at 4.30 but any time before that works for me. > > If that's a problem for Lorenzo, perhaps we can shift the day slightly > > or go earlier in the day? > > The only slot I can in the afternoon is 3PM to 5PM on Wednesdays. > > Morning it is perfectly fine but it may be too early for some people. > > 2PM I really can't make it I am sorry. Maybe we can try in the morning ? > > Please let me know, thanks a lot, > Lorenzo > > > > > 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. > > > > > > > > > > I think we should prepare any topic slides and have the call, does > anyone > > > have any additional agenda items? > > > > I'll chase up our end over the next few days, > > > > Thanks, > > > > Jonathan > > > > > > > > > > > > > > > > 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: > > > > > 1. MMIO / kernel driver. > > > > > 2. PSCI via trusted firmware and system management controller. > > > > > 3. 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 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 mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions >

4 years, 7 months

1
0
0 0

Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting 4 Nov 2020

by Mike Holmes

On Mon, Nov 23, 2020 at 3:13 PM Lorenzo Pieralisi via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> 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@… > ) > > 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 ? It is if we have an agenda, which we now do, I added your topic as confirmed. > If possible 3PM GMT works > better for me; Linaro has a standing internal meeting with its members at 3.00 pm on December 2nd, how is 4.30 pm GMT or retain the 2.00 pm slot? > 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. > I think we should prepare any topic slides and have the call, does anyone have any additional agenda items? > > 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: > > 1. MMIO / kernel driver. > > 2. PSCI via trusted firmware and system management controller. > > 3. 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 mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions > -- Mike Holmes | Director, Foundation Technologies, Linaro Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org> "Work should be fun and collaborative, the rest follows"

4 years, 7 months

3
2
0 0

Re: [Linaro-open-discussions] [Lkq-dev] CompassCI and LAVA/LKFT

by Jammy Zhou

Hi, Below are some meeting minutes for the meeting yesterday. Attendees: - openEuler: Fengguang, Kaitian - Huawei: Nan, Jonathan, Jerome - Linaro: Milosz, Anmar, Ryan, Yongqin, Jammy Notes: - Fengguang did some introduction about CompassCI testing framework - Fengguang summarized the major benefits of LAVA/LKFT to CompassCI - LAVA dispatcher can support many device types - LKFT test definitions can be wrapped in lkp_tests (both lkp jobs and lava jobs are in YAML format) - Anmar asked if we can wrap lkp tests in LKFT, which is also possible according to Fengguang. But Fengguang's recommendation is to wrap LKFT in lkp, because LAVA has some limitations to support the data model of CompassCI. - Anmar asked the database support in CompassCI, and Fengguang shared that ElasticSearch is used now as the database backend to store data - Yongqin asked if there is any plan to support Android by CompassCI. There is no active plan at this moment, and since CompassCI is part of openEuler community, the server OS is the focus now. - The reports for Android Common Kernel testing can be found at [1] - The lkq-dev mailing list [2] can be used for further discussions. [1] https://qa-reports.linaro.org/android-lkft/ [2] https://op-lists.linaro.org/mailman/listinfo/lkq-dev Regards, Jammy On Sun, 15 Nov 2020 at 13:19, Jammy Zhou via Lkq-dev < lkq-dev(a)op-lists.linaro.org> wrote: > Hi All, > > CompassCI [1] is a new CI testing framework being worked on by the > openEuler community, and the implementation is available in gitee repo [2]. > > We're going to have a conference call to discuss the potential > collaborations between CompassCI and LAVA/LKFT. The tech leader of > CompassCI will do some introduction about CompassCI and present their ideas > about integrating LAVA/LKFT with CompassCI. Below is the meeting info and > welcome to join. > > Topic: Compass-CI and LAVA/LKFT sync > Time: Nov 17, 2020 09:00 PM Hong Kong SAR (UTC +8) > > Join Zoom Meeting > https://linaro-org.zoom.com.cn/j/97479537073 > > Meeting ID: 974 7953 7073 > One tap mobile > +16699009128,,97479537073# US (San Jose) > +12532158782,,97479537073# US (Tacoma) > > Dial by your location > +1 669 900 9128 US (San Jose) > +1 253 215 8782 US (Tacoma) > +1 301 715 8592 US (Washington D.C) > +1 312 626 6799 US (Chicago) > +1 346 248 7799 US (Houston) > +1 646 558 8656 US (New York) > 888 788 0099 US Toll-free > 877 853 5247 US Toll-free > Meeting ID: 974 7953 7073 > Find your local number: https://linaro-org.zoom.com.cn/u/aFYmaUrqs > > [1] https://compass-ci.openeuler.org/ > [2] https://gitee.com/openeuler/compass-ci > > Regards, > Jammy > -- > Lkq-dev mailing list > Lkq-dev(a)op-lists.linaro.org > https://op-lists.linaro.org/mailman/listinfo/lkq-dev >

4 years, 7 months

1
0
0 0

Re: [Linaro-open-discussions] Linaro : Meeting : Linux Kernel Discussion : Wednesday Meeting notes

by Hanjun Guo

Hi Ulf, Sorry for the late reply, please see my comments inline. On 2020/11/6 22:37, Ulf Hansson via Linaro-open-discussions wrote: > On Fri, 6 Nov 2020 at 09:53, Mike Holmes via Linaro-open-discussions > <linaro-open-discussions(a)op-lists.linaro.org> wrote: >> All >> >> Thanks for a good discussion yesterday, Hanjun's Unconre DVFS slides are >> now attached to the notes at >> https://collaborate.linaro.org/display/LOD/2020-11-04+Meeting+Meeting+notes > Just to make sure people know about it... > > For DT based platforms we have recently enabled a generic solution in > the Linux kernel to support DVFS. From a top level point of view, it > consists of letting a power-domain provider act as the backend driver > for changing the performance state (voltage/frequency). The mapping of > what state to select, is done through OPP tables. > > I am not an expert of ACPI specifications, but perhaps the DT bindings > can be used as inspiration for what is missing!? Could you point me to the patches or documentation? Thanks Hanjun

4 years, 7 months

3
2
0 0

CompassCI and LAVA/LKFT

by Jammy Zhou

Hi All, CompassCI [1] is a new CI testing framework being worked on by the openEuler community, and the implementation is available in gitee repo [2]. We're going to have a conference call to discuss the potential collaborations between CompassCI and LAVA/LKFT. The tech leader of CompassCI will do some introduction about CompassCI and present their ideas about integrating LAVA/LKFT with CompassCI. Below is the meeting info and welcome to join. Topic: Compass-CI and LAVA/LKFT sync Time: Nov 17, 2020 09:00 PM Hong Kong SAR (UTC +8) Join Zoom Meeting https://linaro-org.zoom.com.cn/j/97479537073 Meeting ID: 974 7953 7073 One tap mobile +16699009128,,97479537073# US (San Jose) +12532158782,,97479537073# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Washington D.C) +1 312 626 6799 US (Chicago) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 974 7953 7073 Find your local number: https://linaro-org.zoom.com.cn/u/aFYmaUrqs [1] https://compass-ci.openeuler.org/ [2] https://gitee.com/openeuler/compass-ci Regards, Jammy

4 years, 7 months

1
0
0 0

Re: [Linaro-open-discussions] ACPI Generic Initiator support status and potential additions

by Lorenzo Pieralisi

On Wed, Nov 04, 2020 at 01:23:43PM +0000, Jonathan Cameron via Linaro-open-discussions wrote: > Hi All, > > This one made it onto the list of topics to discuss (now marked as no need > to discuss). I've been meaning to give a status update by email including > what is outstanding here. Please let me know if this fails to cover > some aspect of interest. > > Background: > > https://github.com/hisilicon/acpi-numa-whitepaper/releases/tag/v0.93 chapter 3. > > Generic initiators are a concept in ACPI 6.3 (sec 5.2.16.6) to plug a hole > in the definition of proximity domains. > > Proximity domains in ACPI (NUMA nodes in kernel) are defined by entries in SRAT > table. There are a whole range of different types of SRAT entry but before > ACPI 6.3 this more or less in practice meant that a proximity domain only > existed if it contained either (or both) memory and CPUs. Other initiators > of memory transactions such as network cards can be assigned to an existing > proximity domain via _PXM in ACPI DSDT. This restricted them to sharing a domain > with either memory or processors. > > That doesn't always reflect system architecture, particularly with the addition > of richer descriptions of access characteristics (latency / bandwidth) brought > in by HMAT. Hence Generic Initiator domains to allow you to specify a > proximity domain with some other type of device in it (such as a network card) > and get all of the descriptive capability available for CPU / memory nodes. > > Note that this was brought in prior to CXL becoming public but 1.1 CXL spec > states that initiators on CXL should be described using Generic Initiator nodes. > This should accelerate the number of users of this feature considerably. > It is also useful in some existing systems. > > What support was needed in kernel: > > 1) Parsing of the SRAT Generic Initiator Affinity Structure > 2) Instantiating the NUMA nodes that map to the GI PXM nodes to ensure stuff > like fallback lists for memory allocation work as normal. > 3) Richer use of HMAT access characteristics to differentiate nearest CPU > to memory from nearest initiator to memory. > 4) PXM assignment from the SRAT record rather than _PXM (not yet done). > 5) PCI PXM assignment (not yet done) > > Status: > > The kernel patches sat on the list (with rebases) for well over a year > failing to get the architecture review needed (as there was significant > risk of breakage in both ARM64 and x86). It was to break this blockage > that we were interested in an open discussion on this. However, they did > recently get x86 review this and Rafael queued them for 5.10 (now merged) > > The PCI PXM issue has been long standing due to some buggy firmware > on certain X86 boards and the need for a clarification in the ACPI spec > (added in 6.3). To make this safe, needed to ensure that NUMA nodes on > ACPI systems can only be instantiated during the main parse of SRAT. > > https://lore.kernel.org/linux-mm/20200818142430.1156547-1-Jonathan.Cameron@… > > That fix is now in place, and we'll resend the PCI fix shortly. Overall, this is a topic to be discussed since it is important. Shorter term, I need to pick your brain on this: 1) The series above, it should fix this issue: https://lore.kernel.org/lkml/26284ca5-ea05-0496-629d-9951f49dda8f@linux.ali… Correct ? 2) Why in dummy_numa_init() (arch/arm64/mm/numa.c) we don't turn numa_off == true if numa_add_memblk() fails ? (Side note: I really like the comment :) "...It is unlikely that this function fails." Forgive me for not looking earlier into the series above that Rafael merged - as I said above this deserves more attention on my side. Thanks, Lorenzo > Note it may be "interesting" to support nodes from CXL CDAT tables at runtime > but that is another topic. > ( https://uefi.org/node/4093 https://lore.kernel.org/linux-cxl/20201102183428.00005f4f@Huawei.com/T/#m52… ) > > For a Generic Initiator Nodes, there are two ways a device an be assigned > to the proximity domain. Conventional _PXM in DSDT can be used and > that is now supported. The SRAT entry itself also contains an address > (PCI seg + BDF or Platform UID / HID based). There is no obligation to > provide both. The SRAT based method will require some level of alternative > infrastructure to that used for _PXM. We may look at this at some stage. > > So a few outstanding things but probably not worth discussing on a call > at this stage unless anyone is seeing problems with the stuff already merged. > > Thanks, > > 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

4 years, 7 months

2
1
0 0

2025

2024

2023

2022

2021

2020

Linaro-open-discussions