-
Notifications
You must be signed in to change notification settings - Fork 294
System Device Tree Meeting Notes 2021
Nathalie Chan King Choy edited this page Jan 29, 2021
·
8 revisions
- Tomas - Xilinx
- Stefano - Xilinx
- Frank Rowand - Sony
- Dan Milea - Wind River
- Dan Driscoll - MGC
- Krzysztof Kepa - GE Research
- Bruce Ashfield - Xilinx
- Kumar G - Linaro
- Loic Pallardy - ST
- Ben Levinsky - Xilinx
- Hannes Tschofenig - Arm
- Rob Herring - Arm
- Mark Dapoz - Wind River
- Ed Mooring - Xilinx
- Arnaud Pouliquen - ST
- I would also like to cover again the remoteproc bindings and they get generated from system device tree.
- I would like to continue the discussion on the bus firewall bindings. I sent an email to the list with the summary of the past discussions.
- If we have time, we can discuss how system device tree aligns with ffa partitions definitions.
- Loic: Check HW lock bindings
- Stefano: Will try to combine the 2 properties into 1 & come up with some examples.
- Recording: (I am not sure how long before the recordings expire or I will hit my storage limit, so if you need to catch up by watching the recording, please download it in the next couple weeks) Recording link System DT call
- Announcement: Linaro Connect session accepted: DTE state of the union from 4 perspectives: Bill Mills, Kumar, Stefano, Wind River
- Stefano: Remoteproc bindings have made good progress in the past year
- Showed original Xilinx remoteproc binding & Ben recently posted to upstream revised Xilinx binding based on feedback (thanks to the reviewers)
- Showed TI K3 binding & is much more aligned. Stefano has slide listing the commonalities.
- Kumar: What is Linux doing with sram property? Can be helpful to specify the property outside of Linux.
- Ben: Application specific, or IPC
- Rob: R5 is common from Arm & have 2 different bindings for it between Xilinx & TI
- Loic: Agree we can find common foundation between the drivers for the co-processors
- Rob: There are common parts. Focused on R5
- Kumar:
- There's value in defining a common binding.
- Remote proc state machine could be common too
- Rob: There is a start on work on that. Have acked.
- Showed System DT representation for Xilinx bindings. Interesting part is in domains node.
- Access: Give unique access to something
- Include: Include shared resources
- Pass to Lopper as input. Ben created Xilinx-specific plug-in in Lopper repo, assists.
- Stefano: Bus firewall bindings
- Another way to call it is is system-wide MPU
- Doesn't fit interconnect bindings well
- But maybe very similar to IOMMU bindings
- What's missing: How to specify the slave side connection (e.g. firewall property)
- Currently assume IOMMU covers everything in address space
- Rob: Another issue: What if you have an IOMMU & a firewall? Probably makes sense for these both to be separate.
- Rob: Why can't bus master ID & firewall be same property?
- Stefano: Could, if we had a way to distinguish them
- Rob: That node defines what each one is.
- Stefano: Could define positioning
- Loic: Driver in Linux must be able to check what it's allowed to access IP register before probing.
- Loic: Need to investigate if can do at kernel level, if we can't add this new property.
- Loic: If have several drives, have to know know which reg value
- Stefano: Makes sense to have slave side info there, to know what's protected. Shouldn't have to encode in drivers or Lopper - can. Xilinx lopper plug in to pre-generate configuration of bus firewall @ low-level details. Could be hard-coded in Lopper plug-in to cover slave side, but makes System-DT description incomplete.
- Kumar: Makes sense to describe b/c non-Linux SW cases. TEE or boot firmware might be configuring the firewall, and needs the info.
- Kumar: What is firewall property in CAN case?
- Stefano: MMIO region starting at 0xff06000 is protected by system-wide MPU. So, if you want to block everyone except 1 master to make DMA txn for that region, you have to go to lpd_xppu. Unlike w/ IOMMU, not all areas are protected.
- Loic: Need additional ID for ST b/c not based on memory region, but rather peripheral identifier. Have hard-coded entries in peripheral firewall, similar to clock & reset. -> firewall-cells after phandle in firewall property. Other SOC vendors have HW semaphores to get access to peripherals, so SW that wants to access peripherals should 1st do something at firewall level to get access & then do something.
- Rob: HW lock binding exists for that, but don't have to use here.
- Loic: Will check HW lock binding. Think it's complement. Firewall adds check of access right + lock.
- Kumar: 2 ways in DT to describe directionality. 1 way: memory & DMA ranges for in & out view that's CPU-centric. Interrupts: Interrupt nexuses w/ graph-based view, where we don't separate direction based on property name. Should we move more to interrupt way of describing things?
- Rob: Should be able to combine into 1 property & say there's always at least 1 cell & that cell says master or slave & subsequent cells are ID values.
- Stefano: that would make it easier
- Rob: Not sure if you need master & slave ID. Could walk the list to find firewall properties & firewall property entries. Based on cell value could know if slave or master on that system.
- Stefano: That might work too
- Rob: Assuming address range might break if >1 reg entry, generically
- Stefano: Different slave ports on different reg entries?
- Stefano: Assumption: Each node, even if it has multiple regs, are all slave the same way & master the same way. No different master & slave config for each reg entry of 1 node. Think it holds true on our boards.
- Rob: Cell values could be address, even if duplicated. May be a subset of reg entries.
- Stefano: Good idea. Could put it as a 1st ID after lpd_xppu
- Rob: Generally cells only completely meaningful to phandle they are associated w/. If common, would be convenient.
- Stefano: Will try to combine the 2 properties into 1 & come up with some examples.