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

Jammy Zhou jammy.zhou at linaro.org
Tue Nov 24 01:13:03 UTC 2020


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 at 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
>


More information about the Linaro-open-discussions mailing list