Kumar: It's not a DT-specific problem, ACPI and other solutions would run into the same issues.
Olof: DT misses a way to express Linux-only data. If we switch to something else, we should use a Linux-specific solution.
Grant: Putting configuration data in DT isn't such a bad thing, but it shouldn't contain Linux internal details (such as "load this driver"), as those can change pretty dynamically.
DavidB: How much of the problem would be solved by splitting DT in several trees (HW data, config, ...) ?
We have the chosen node that could be used for configuration purpose. That would extend the traditional/historical use of the chosen node.
Kumar: This would replicate the SoC hierarchy under another node, which would get messy.
Tony: Using initramfs we could switch to configuring the kernel from userspace (MAC address, ...)
Grant: Forcing using specific command line parameters to boot on production system isn't a good idea. The firmware should provide enough information to find the boot device.
Kumar: Parameters could easily be passed in "linux,..." device DT nodes. The real issue is whether we want DT to be a stable ABI. We know we won't get it right the first time.
ThomasP: The other kernel stable ABI is the syscalls, which evolve very slowly for that reason, even though they're much more limited in scope.
Grant: "Not breaking things" might not mean a stable ABI.
LaurentP: Not having a stable ABI isn't a regression compared to the board code situation. If the .dts is in mainline everything will work. If it isn't, it's the same situation as out-of-tree board files.
Grant: We have a core set of properties that we can standardize as an ABI (ranges, interrupts, GPIO, ...). Problems come from more complex use cases such as DRM
Mark: The DRM problem is more a modularization issue than a DT issue.
DavidB: The solution might be to solve the problem with the server/laptop market and leave embedded systems as-is without a stable ABI.
Pawel: Problems don't come from adding properties but from removing or changing the meaning of existing properties. There's no chance we'll get the bindings right in the first place.
Grant: We should not break bindings needlessly.
Kumar: "compatible" should be what the hardware is compatible with, not what the software is not compatible with.
If noone has every shipped a device with a given binding we can change it. But how to know what has shipped ? Lots of people run out-of-tree device trees, but we can have an educated guess.
MarkR: Xen and KVM generate and provide device trees to the kernel, this needs to be taken into account.
Grant: For things that are under heavy development we need to let bindings get merged without ABI requirements. Bindings could be marked as stable 6 months later. Creating a spec without a working implementation doesn't work anyway.
Kumar: New systems are more and more complex, putting all information in DT might make the device tree too complex. The data-driven approach is nice, but might not be the solution for everything.
Grant: SoC-specific code isn't a problem.
Magnus: For development it would help to use old-style platform devices.
Kumar: We can do that with stripped-down bindings (reg, interrupts, ...) and get the rest of the data from auxdata.
Arnd: That won't work for the long-term goal where we want no code for a particular platform in arch/arm/. All data needs to go in DT in that case.
Olof: When we started it was about whether we can support a board without board code.
Grant: Maybe it is olay that we have these poor bindings with Linux specific data in them? Okay, they're not *nice*, but thye do work ("perhaps we've been too hard-line on this")
Grant: We can't stall development for the next 6 or 12 months until we get the toolings in place. The largest concern here is about bindings that abuse core properties (reg, ...).
ThomasP: The thing that causes the DT review stall isn't the basic "should this be a boolean or integer" but is trying to find a generic enough way to describe all use cases cleanly.
Olof: Why is noone reviewing that ?
Kuwar: There's too much noise on the list.
Grant: Don't post your entire series to the device-tree list.
MarkB: git-send-email doesn't help there.
DavidB: Can we get git-send-email and get-maintainers to cooperate ?
RobH: All we need for review is documentation (Grant: And the schema, when we have it)
TomaszF: We need to define what a DT binding is.
Grant: Let's document that. Any code that has DT parsing in the commit should either point to the bindings document, or has a DT bindings document patch in the series. The DT bindings should be on their own patches.
RobH: should the binding be merged separately?
Grant: If it is a patch series, this doesn't matter, it can all go together
Olof: We get enough conflicts already - can different people send these tings to the different maintainers and then "when it all hits linux-next your device works"
Grant: If we make a change that breaks the ABI, merge the dts and code in the same branch.
Simon: That's only when we need to make an atomic change. The common case is that things can be in separately.
DavidB: We need a tool that can parse a patch series and flags missing DT documentation.
Kumar: What happens when we move bindings out of the kernel tree? Do we need to take the code out of checkpatch? Does the the other tooling need to change
Grant: I think we need to back away from that... Perhaps we can't pull these things out
-- Is Linus okay with that? Grant can ask him...
Grant: We need to reach the point where we can say: What are the simple rules to tell all maintainers so that we can break this log-jam?
[...] more discussion on whether to send the whole series, does it just create noise or is it valuable [...]
Grant: Possible conclusion: bindings in a simple patch, maintainers must have an eye on that, and if bindings don't get reviewed in X weeks they can be merged.
Arnd: Last time we talked about this we concluded we would have stable and unstable bindings - that should probably be included in the 'conclusions' from today
DavidB: It should be *in* the schema to specify whether the binding is stable or not
MarkR: These things *aren't* actually all in driver code - they touch multiple systems that interact.
Grant: Those things are still very much in flux. We need to trust subsystem maintainers
Pawel: We've been too specific about this in the past.
Kumar: Multi-subsystem bindings should have much more review.
Pawel: ... agree, but we should be having more faith in subsystem maintainers.
Wolfram: Is see things are stalled and I want to fix that, but the concern is that we're also accepting things too easily sometimes. Platform-specific bindings that should be subsystem-specific are often accepted. One good side of DT is that it should push people to think about whether something should be generic or driver-specific.
Grant: The process is still going to be "all bindings have to go to the DT list, and the volume should decrease if we're only sending bindings to that list. Hopefully the reviewers will be able to catch up... All bindings *should* then get some review
Kumar: The responsibility of catching driver-specific properties that should be subsystem-specific should be on subsystem maintainers.
Grant: subsystem maintainers are in a better place to catch certain types of problems than the DT reviewers - subsytem maintainers still need to be able to say "no, that's crap"
Stuart Yoder: Can we require that the binding go in first. If we say "the binding has to go in first, before we accept the rest of the driver" then it will force people to think hard about their binding in the context of the driver
?: that would happen in a separate tree
Grant: We need to back off on splitting trees for at least 6 months, we need to fix the block first.
WillD: I object - we're now saying "send us loads of crap code and it'll go in to mainline" - so to avoid this we *have* to have things go via the subsystem maintainer if things haven't been reviewed within the two-week window
-- there should be a way for subsystem maintainers to push back to the DT people
Grant: Should the policy be that the binding has to be ack'd by the subsytem maintainers?
many: yes, we should
Binding must be acked by subsy maintainer
Binding should be looked at by DT people *but* if they're 'sleepy' it rests with the subsys maintainer
JonathanCameron: Is it the case then that subsystem maintainers are welcome to say "DT people were too slow, I' ve merged that"
Grant: yep - that's okay
LinusW: Subsystem maintainers get forced to learn about all the possible hardware description mechanisms to be able to review patches, which is a problem.
Arnd: some people making bindings know exactly what they're doing and just need an Ack, some people *don't* and need more handholding
Grant: What we need to do today
- Document policy
- Statement on what ABI actually means: What IS ABI and what is NOT (What's stable and what's not)
Olof: We have not heard any dissenting voices in this room over [...] stable bindings
rmk: If you put something into the kernel, and the kernel gets released as a final version, this makes the thing ABI. Previously we've said that to remove anything in this case you *need* to go through a deprecation process. We seem to be adopting a new position with DT here. We seem to be saying "even if we do put it in to the kernel we can change it as much as we like" - and people are doing bindings out of the tree. If we want to have unstable bindings we need to have a way of documenting that they're unstable..
Grant: this adds a third thing for today - make a way to explicitly state the stability.
Stephen: should default be unstable?
?: We need more than two classes: there's not just stable and unstable, there's the time when you're reworking stuff.
rmk: Rather than using a directory to sort this out, can we use a filename as the way to specify this [...]
Olof: we're adding 'tribal knowledge' here that people need before they do this
Grant: We should have a 'trivial' file of Docs - put the simple stuff in there.
Olof: Coming back to rmk's point of out-of-tree drivers, perhaps we should ask people to put them in the tree?
Will/Marc: Hey! What about KVM/Qemu because they *generate* their trees
(Feel free to help taking notes, I won't be able to catch everything :-))
? Should the clock data go into the DT or into C source?
- Mike/Magnus: it should be fairly readable in the DT
- Mike: am planning to come up with a standard set of structures for registering clocks from C code
- The choice between C and DT data is probably best made on a SoC-specific basis
? What about STI? Has clock registers scattered all over its SYSCON IP block
- several hundred kilobytes of address space
-> should just have one DT device for SYSCON and locate all of the clocks underneath it with offsets
Mike: am more than happy for folks to put device-specific clocks into individual drivers
- model the hardware as it exists
- parent node should own all of the registers
- From the DT perspective, we try to avoid having multiple nodes that all have the same numeric address after the @ sign
Mike: existing clock bindings are a problem - we wouldn't do it the same way again
- strings are used to link clocks in non-DT situations
- Arnd: to change this, we'd have to change all of the existing DT data
Paul: what's the use-case for the top-level clock nodes?
- Mike: not much of one
- Arnd: intention is to use it for fixed-rate clocks supplied by the board
- Magnus: we have several different senses of topology - clock topology vs. bus topology
LinusW: ST-E PRCMU is a Cortex-M3, completely software defined
Mike: am wanting to put register-level data into DT
- pretend we only have one clock per 32-bit reg
- am OK with placing a bit-offset property into DT
- Arnd: you have to give it the right name
- like 'index' rather than 'bit-shift'
- Mike: working on OMAP with Tero
- have 16 specific clock types
- OMAP doing a one node per clock approach
- Maxime: already doing this with Allwinner
Mike: try to avoid gluing different clock types into a large macro clock
- e.g. divider + gate
DT preprocessor macros: when to use it?
Maxime: has been requested to remove binding documentation
Thomas Petazzoni: that is not very nice because I use the binding documentation
Clock index numbers aren't an artifact of the hardware, unlike interrupt numbers
? Should we limit the number of ways to identify clocks in DT, across different SoCs?
- Mike: would like something that reduces the size in the DT
- Arnd: would like Mike to specify a preference for guidance for others
- Mike: will have to get back to folks on preference
Paul: >2GHz clock rates
- rmk suggests 64 bit interfaces and I agree
- modify clk_round_rate() to not return errors
- Mike is fine with that
- Some concern about 64 bit divide overhead
- standardize interface to microcontrollers for PM functionality (remoteproc/rpmsg) (Kevin Hilman)
Should there be a standard interface?
LinusW: May not be under the control of the kernel guys
- At ST/E, we were inspired by rpmsg
- So a good example can go a long way
Kevin: remoteproc/rpmsg is pretty heavyweight
Vincent: not so bad
LinusW: MIPI is looking into this
Kevin: thinking about the BeagleBone
- has an M3 to handle low power transitions
- TI moving functionality into firmware to avoid upstreaming problems
- should we have a recommendation for others?
Vincent: common interface could come from the scheduler interface?
Kevin: we want the minimum possible done by the firmware
Should it be improved to understand things that are not just CPUs
- Catalin: would like to keep PSCI scoped to CPUs & caches
Catalin: It was originally done for CPU power management specifically, but now has 'system' bits too. (for reset and power off)
Catalin: TC2 has a power microcontroller also
Tony: for BeagleBone, it should be under drivers/
- no reason to initialize it early and shouldn't be under arch/arm
Should we mandate using things like rpmessage?
Kevin: We should mandate remoteproc, but rpmessage looks heavy...
PaulW: Sometimes the firmware can be loaded super-early, before the kernel starts, so it might be necessary to patch remoteproc to skip firmware loading
Does switching to rpmessage mean changing the firmware?
- we're likely to need a driver per firmware
- we should make rpmessage nice enough that people will jump to use it.
Kevin: so should someone be working on rpmessage to make it nicer to use
LinusW: The bit people want is the data path, not really the control path
Kevin: if the control path is very simple, and rarely used, then it is a lot of overhead for not much gain.
Tony: let's put this under drivers, initialise it with remoteproc.
Kevin: Beaglebone is broken! Mailbox doesn't actually work, but it is used to trigger an interrupt, the M3 side can't see it though so the A-side has to read-back to stop the fifo filling up :/
Kevin: Russ Dill has proposed a general purpose system for compiling position-independent C-code that gets run from SRAM
How we plan to share things like platform_suspend_ops and hotplug implementations across arm and arm64. Will we be moving that code to drivers/power? (Stephen Boyd)
- Catalin: put it in firmware :-)
- Mark Brown: pick a directory
[...] sharing platform power management code between V7/V8
Sboyd: pm and cpu-hotplug are the things requiring the mach directory to still exist
Should we have drivers/power then?
Kevin to sboyd: Just move your stuff into drivers/power and see what happens (!)
Automated power regression testing
MikeT: If there are specific tests that someone wants testing, then we should let him know.
Runtime PM vs. suspend, the never-ending saga
Runtime-pm: We should be moving to this world, but so far there doesn't seem to be a huge amount of adoption.
- Adoption common where the subsystem abstracts it somewhat to avoid splattering runtime-pm calls all over the code.
- Reduce the amount of boilerplate required makes people more likely to do this
LinusW: Mixing suspend and runtime-pm is difficult.
Kevin: With agreement from pm-core people should mean this moves on
Mike's patches to automatically control regulators
- Kevin suggests merging them
Lee Jones cares
Upstream devfreq is completely broken
- Mike: only appropriate for non-CPU processors like GPU or bus
- MMC controllers would never use devfreq
- LinusW: typically IO devices are given specific rates
Moving away from OPPs to "P states"?
Mark Brown: what about PM QoS?
Mike: should there be a separate DVFS framework?
Paul: why should drivers care about what integration clocks need to be changed?
Mike: generic DVFS layer
- should not be CPU-centric
PaulW: Constraints between voltage rails
MikeT: is it tied to frequency
PaulW: Yes, it is going to be tied to Freq. This is likely to be a common problem.
Conclusion and Readouts
Device Tree Process
- Codify things to talk about on Friday with full KS
- Stable vs. unstable
- Public shaming for breaking bindings
- More documentation for creating forward-compatible bindings
- Debate on the discussion that Stephen started
- "Err on the side of simplicity"
* Grant to set up a conference call next month to discuss all this
- Two-week timeframe - if no DT-list review occurs, subsystem maintainers should feel free to merge
More documentation required explaining how to write bindings
- keep things simple, light to start with (standard, well defined core properties)
Mark Rutland offered to write the docs - co-ordinate with Tim Bird/CELF(?)
Device Tree Tooling
- considered both (Benoit's, Tomasz's) proposals for schema formats
- considered scope of validation required
- found out that can't really define a basic initial format of schema first, without considering the full set of what we'll like to validate, or we'd be left with a schema format that's too restrictive to extend later.
- considered trade-offs of .dts -vs- C syntax for the schema representation. No firm decision yet.
- haven't really got enough time to conclude this discussion so far. Follow up session required. (a bit closer to a solution, but nothing finally decided)
- Next step: look through existing bindings and enumerate the things that we eventually want to be able to represent.
Power Management Discussions
Highlights: runtime-pm vs system-pm
- over the last year the core pm maintainers seem to have reached a conclusions that they like the runtime-pm view of the world
- some disucssion about why runtime-pm hasn't really been adopted
- better to do it in the subsystem level not the driver level
- some level of laziness
Some talk about the trend towards PM being done on microprocessors
Can we standardize?
- remoteproc seems useful
- rpmessage seems perhaps too heavy
Platforms doing things in homebrew ways at the moment.
How can we share PM code between arm and arm64?
- Catalin wants it all in firmware, but things that can't go there should go in to drivers/power
Action item: MikeT to publish clock rate change notifier series (so people can take a look!)
bindings and configuration:
How to craft better/more acceptable clock/DT bindings
- lightweight clock controller binding.
- declare bindings and make phandles available
- more heavyweight version that required data in the DTS (MikeT to go over this)
System for setting aside regions of memory (say for DMA) early in boot that can subsequently be used by CMA/Ion etc
Laura to polish up what was decided, Grant to look at existing patches. Code expected this week (!)
What tools should we worry about/what do we need to do
- for initial use-cases we probably won't need to use shim.
- some concern about using non vfat file-systems as this might require shim
- we want to find simple ways to verify that the basics function on ARM
need to look into IPMI (especially as early platforms will be server platforms)
Olof: This has been larger than past events - how has it worked? What might we change next time?
- Splitting into two rooms makes it difficult to know where to be (though, there's not a clear solution to this)
- Has there been too much talking? Some people hacked, and people seem comfortable with the level of each activity
- Should we take the DT stuff out of ARM?
HPA: For 20 years, we've run on firmware designed for other operating systems. We're moving in to a world where that can't be expected, and this is a cross-architecture problem now.
Does it make sense to break embeded out from the server activity?
- no! don't sweep the embedded stuff under the rug/keep it out of the light.
- we should have an idea of what's going on across the ecosystem.
Linux firmware summit!?
Was the 'fuzzy' scheduling good?
- the only problem was co-ordinating between the rooms.
- rooms being far apart wasn't planned, really
- would a more rigid 'unconference' system be useful?
- time-slots might help
- rooms being closer would help
(things were a little noisy at times)
Do it again next year!
- or sooner?
Linaro shouldn't be the centre of this, really.
Grant's advice on making this practical: Look at the LF events - find one that we can 'tag on to' and run in parallel with that.
- ELC is a good candidate.
- Co-location with ELC/ELC-E proposed by Olof.
Grant claims boldly that it is a light load to organise these.
(one of the biggest difficulties is choosing attendees/making the right decisions)
Grant to grab copies of all the notes tomorrow, so add them to the Etherpad documents ASAP.
Core invite attendees: 6:30 at Cucina (6:15 bus departure)
Workshop attendees: LinuxCon + CloudOpen Reception, 7:00 National Museum (6:45 bus departure)
TAB Elections: 9:00 at the National Museum in the Connect Gallery