[U-Boot] [PATCH] vexpress64: compile Juno PCIe conditionally

[Ryan Harkin]

On 20 October 2015 at 16:38, Tom Rini <trini at konsulko.com> wrote:

> On Tue, Oct 20, 2015 at 08:05:40AM +0200, Linus Walleij wrote:
>
> > Only compile in PCIe support if the board really uses it. Provide
> > a stub for the init function if e.g. FVP is being built.
> >
> > Cc: Liviu Dudau <Liviu.Dudau at foss.arm.com>
> > Cc: Ryan Harkin <ryan.harkin at linaro.org>
> > Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> > ---
> >  board/armltd/vexpress64/Makefile | 3 ++-
> >  board/armltd/vexpress64/pcie.c   | 2 --
> >  board/armltd/vexpress64/pcie.h   | 4 ++++
> >  3 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/board/armltd/vexpress64/Makefile
> b/board/armltd/vexpress64/Makefile
> > index a35db401b684..b4391a71249a 100644
> > --- a/board/armltd/vexpress64/Makefile
> > +++ b/board/armltd/vexpress64/Makefile
> > @@ -5,4 +5,5 @@
> >  # SPDX-License-Identifier:   GPL-2.0+
> >  #
> >
> > -obj-y        := vexpress64.o pcie.o
> > +obj-y        := vexpress64.o
> > +obj-$(CONFIG_TARGET_VEXPRESS64_JUNO) += pcie.o
> > diff --git a/board/armltd/vexpress64/pcie.c
> b/board/armltd/vexpress64/pcie.c
> > index 7b999e8ef40b..311c4500e3ff 100644
> > --- a/board/armltd/vexpress64/pcie.c
> > +++ b/board/armltd/vexpress64/pcie.c
> > @@ -191,7 +191,5 @@ void xr3pci_init(void)
> >
> >  void vexpress64_pcie_init(void)
> >  {
> > -#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
> >       xr3pci_init();
> > -#endif
> >  }
> > diff --git a/board/armltd/vexpress64/pcie.h
> b/board/armltd/vexpress64/pcie.h
> > index 14642f4f5c43..55b276d6af11 100644
> > --- a/board/armltd/vexpress64/pcie.h
> > +++ b/board/armltd/vexpress64/pcie.h
> > @@ -1,6 +1,10 @@
> >  #ifndef __VEXPRESS64_PCIE_H__
> >  #define __VEXPRESS64_PCIE_H__
> >
> > +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
> >  void vexpress64_pcie_init(void);
> > +#else
> > +static inline void vexpress64_pcie_init(void) {}
> > +#endif
> >
> >  #endif /* __VEXPRESS64_PCIE_H__ */
>
> Alright, so the versatile platform makes life fun at times.


This comes back to the refactoring thread we had recently...



>   First, my
> preference is for weak functions (and I _think_ the linker ends up being
> smart enough about them to optimize things away, if not, arrg).  Second,
> the question I have is, is this xr3pci_init() bit really a Juno thing or
> a baseboard thing (I assume no)


It's sort-of the same thing on Juno.  Juno has a baseboard and SoC in one
build, unlike the previous 32-bit Versatile Express motherboard that takes
core tiles with different cores on it.

Juno R0 has the PCIe controller, but it doesn't work.  So the code is safe
to run at this level.  Juno R1 has the controller and it works.

or a going to be the same on the next
> Cortex-Asomething module thing?


Juno R2 will have the PCIe controller too and it should hopefully work.

But this controller is not Cortex-Asomething related.  Another vendor could
put the same IP block on their board, of course.

FVP models don't have it and other ARM platforms won't necessarily have it.

Does that help?!



>   The way the code stands today a
> hypothethical A72-based vexpress64 module would need to call
> vexpress64_pcie_init()


Hmmm, that doesn't seem right, does it?


but not strictly xr3pci_init().  It would be a
> little ugly as pcie.c would #if/#elif/#endif the enabler call however so
> we could __weak a no-op in board.c and rename pcie.c to juno.c and have
> a72codenameboard.c later on with its own function.
>
> --
> Tom
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>