
+A few others who might be interested in PCI
Hi,
On 24 November 2014 at 12:32, Simon Glass sjg@chromium.org wrote:
This is an early preview of some recent work to support PCI in driver model. It was prompted by fiddling with bare x86 support and finding that PCI has its own device model, but no actual storage as to what devices exist in the system. It is not possible to specify configuration information for devices other than in board code.
This patch is a collection of changes in core DM, sandbox and PCI code to implement a PCI uclass and associated operations. Some basic tests are provided but they are incomplete.
As is becoming common with DM conversions, the existing structure (here struct pci_controller) becomes per-bus uclass data. This allows the concept of a 'hose' (generally a PCI host controller and a bus) to continue to exist in the interim, even if it should not be needed in the end. This makes it much easier to convert over existing code.
There is one major core DM change tacked into this patch. The core DM code is updated to move allocation of platform data into the bind() stage instead of probe(). This is because with PCI we need to know the bus address of a device (in PCI speak: device and function or devfn) before we can probe it. Actually a similar problem arose with SPI and I2C and I worked around it, but with evidence from PCI also it seems we should make this change.
PCI buses are not scanned in the bind() method but only later when probe() is called. This will be automatic if you access a bus, but it does mean that if PCI is not used it will not be touched, in keeping with U-Boot's lazy- init philosophy.
The existing 'pciauto' bus configuration code is still used, although it now uses DM underneath. It works exclusively by reading and writing PCI config and does not refer to DM data structures. In fact that file is not touched in this patch which is an indication that a good level of compatibility is achieved between DM and legacy PCI.
In order to support testing of PCI I/O and memory space, support has been added to sandbox to allow mapping of these. This allows commands like 'md' and 'iod' to display data from mapped PCI devices. Similarly, it is possible to make changes to this space. This support relies on the existing map_sysmem() and unmap_sysmem() calls which are now fairly widespread in U-Boot.
Apart from the driver model tests (run with ./test/dm/test-dm.sh) you can try out these commands which use the new 'swap_case' test device:
../u-boot -d b/sandbox/u-boot.dtb .... => iow.b 20000000 2 => iod.b 20000000 0000: 02 => mw.l 10000000 64436241 => md.l 10000000 1 10000000: 44634261 aBcD =>
This shows an I/O access to 20000000, setting the value 2 which means to swap the case. Then 'AbCd' is written to the memory space at 10000000 and 'aBcD' is read back.
The 'pci' command works to some extent.
Most existing PCI functions still work, but route through driver model. The file drivers/pci/pci.c is replaced when driver model is enabled so not everything is present. Also multiple bus support is untested and probably broken. A new pci_common.c file holds functions common to driver model and the old system, and pci_compat.c contains functions I would like to eventually deprecate.
This series is not tested on any real hardware at this stage. Once the bare x86 support is merged I will tidy this patch up and move it over, fix up Kconfig, etc.
This patch is available at u-boot-dm.git branch pci-working.
Signed-off-by: Simon Glass sjg@chromium.org
Are there any comments on this series please? I plan to do a respin soon.
Regards, Simon