On Fri, Sep 27, 2019 at 7:42 PM Nico Huber <[email protected]> wrote: > > IIRC, I asked this elsewhere already. Do we want to keep simple device? > If we reduce `struct device` to b/d/f and a pointer to the chip info > in early stages, couldn't we just use `struct device` for PCI config > access everywhere?
I got side-tracked from the PCI development, also I noticed the one big [RFC] commit on my local tree I had never pushed. 1. I want to remove all preprocessor #ifdef __SIMPLE_DEVICE__ mess. We currently have that because of name collisions, some of that looked prettier prior to removal of device_t but we definitely do not want that back. 2. I have experimented with romstage, switching from passing immediate BDF value PCI_DEV(b,d,f) to struct pointer; I have not seen performance or code size penalty. Having inspected some of the generated objects, code patterns that transfer multiple register values from devtree.cb to a single PCI device are actually tighter assembly code (on x86). My vision here is we need to optimise the developer's use of time. 3. I want to keep pci_devfn_t available for PCI subsystem primitives, like <device/pci_mmio_cfg.h> and <arch/pci_io_cfg.h>. Also I would like to keep those files simple and see at most an anonymous struct device. I am not convinced if we are ready to really require C_ENVIRONMENT_BOOTBLOCK with next release? The forms with pci_devfn_t do work with romcc and we need that little PCI configuration in bootblocks. 4. I do not want to make devicetree compulsory for (gcc-built) bootblocks. But if we can drop the topology links there, the size impact would not be that bad. If we follow this approach, and get all romstages converted to use struct device, we could reconsider #3. 5. I don't plan to fix/clean amdfam10 from the preprocessor mess discussed here (or elsewhere). Kyösti Mälkki _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
