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

Mike Holmes mike.holmes at linaro.org
Wed Nov 25 11:32:47 UTC 2020


On Tue, Nov 24, 2020 at 11:13 AM Lorenzo Pieralisi <
lorenzo.pieralisi at arm.com> wrote:

> On Tue, Nov 24, 2020 at 09:58:23AM +0000, Mike Holmes wrote:
> > 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 ?
>
> I can only attend at 10am GMT on that day, not in the afternoon.
>
> Or maybe beginning of that week (Dec 1st for instance ?) if we want
> also to give access to people in Americas.
>

Shall we try a doodle poll to find a time?

https://doodle.com/poll/2xib35xfuwbabwd4?utm_source=poll&utm_medium=link

Mike


>
> Thanks,
> Lorenzo
>
> > On Tue, Nov 24, 2020 at 1:13 AM Jammy Zhou via Linaro-open-discussions <
> > linaro-open-discussions at 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 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
> >     >
> >     --
> >     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 at linaro.org
> >   "Work should be fun and collaborative, the rest follows"
> >
>


-- 
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes at linaro.org <mike.holmes at linaro.org>
 "Work should be fun and collaborative, the rest follows"


More information about the Linaro-open-discussions mailing list