[U-Boot] [PATCH] RFC: Add driver model support for PCI

Simon Glass sjg at chromium.org
Mon Jan 5 02:25:11 CET 2015


+A few others who might be interested in PCI

Hi,

On 24 November 2014 at 12:32, Simon Glass <sjg at 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 at chromium.org>

Are there any comments on this series please? I plan to do a respin soon.

Regards,
Simon


More information about the U-Boot mailing list