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@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@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:
- 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. Possiblypursue
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
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.
Thanks, Lorenzo
On Tue, Nov 24, 2020 at 1:13 AM Jammy Zhou via Linaro-open-discussions < linaro-open-discussions@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@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@linaro.org "Work should be fun and collaborative, the rest follows"
On Tue, Nov 24, 2020 at 11:13 AM Lorenzo Pieralisi < lorenzo.pieralisi@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@op-lists.linaro.org> wrote:
Some earlier slots can be better for potential attendees from Asiain the
early evening :-) Thanks, Jammy On Tue, 24 Nov 2020 at 02:25, Lorenzo Pieralisi viaLinaro-open-discussions
<linaro-open-discussions@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 at3.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 forme.
> > If that's a problem for Lorenzo, perhaps we can shift the dayslightly
> > 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 somepeople.
> > 2PM I really can't make it I am sorry. Maybe we can try in themorning ?
> > 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 topicsthat
> > > > 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 soonerwe
> 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 eachfirmware
> type. > > > > > * Lorenzo / Sami to check IORT revision E is final. > > > > > > > > > > SVA > > > > > === > > > > > > > > > > Zangfei gave summary: > > > > > - Huawei has devices that are not PCIe but are presentedas
such. > > > > > - They support stall mode for SVA (spec violation) > > > > > - Resistance from kernel maintainers to maintaining awhite 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 tosend out
> this > > > > cycle). > > > > > - If longer term fix need add can't be done via PCISIGetc then
> need to > > > > convince > > > > > PCI and SMMU maintainers. Noted that quirk is verylittle
> code. > > > > > > > > > > * Other SVA topics. > > > > > - Mentioned virtual SVA (no actually problems justexpressing
> > > > interest!) > > > > > - Would need Eric Auger, wasn't on topic list so Ericnot on
> call. > > > > > > > > > > AI: Nothing planned until after JPB has upstreamed stallmode.
> 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 andfrequency for
> ACPI > > > > based systems. > > > > > > > > > > 3 options: > > > > > 1. MMIO / kernel driver. > > > > > 2. PSCI via trusted firmware and system managementcontroller.
> > > > > 3. ACPI (wrapping up an op region and SCMI) > > > > > > > > > > Clarifications / discussions. > > > > > * Vincent G: Power states, or voltage frequency ofinterest? Ans
> > > > Voltage Freq > > > > > * Considered SCMI? Ans: Works only for DT as SCMI underACPI 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. Notjust
> CPU. > > > > For example PCI device accessing > > > > > memory may well need the ring bus to be fast. > > > > > * Vincent G: Bandwidth affected? Yes. VG: mobile doesthis 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? Wemight need
> to add > > > > to the spec. > > > > > * Sudeep H: What are the requirements? gaohanjun: Now wejust
> > > > 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 talkin ASWG
> about > > > > DVFS > > > > > * Jonathan C: For now direct control probably makessense.
> Whilst it > > > > would be nice to have > > > > > a detailed enough system description in a standard wayto make
> > > > general software that is a > > > > > big spec job. > > > > > * Jonathan C: Seems like true standard SW will not happenany
> time soon. > > > > > > > > > > AI: RFC to the linux-pm / linux-acpi Rafael and those inthis
> 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 theydidn't
> agree to > > > > then please > > > > > correct that. > > > > > > > > > > Thanks all for contributions. I for one found it a veryuseful
> 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 listhttps://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@linaro.org "Work should be fun and collaborative, the rest follows"
linaro-open-discussions@op-lists.linaro.org
-
Lorenzo Pieralisi -
Mike Holmes