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

Lorenzo Pieralisi lorenzo.pieralisi at arm.com
Mon Nov 23 18:25:06 UTC 2020


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


More information about the Linaro-open-discussions mailing list