[U-Boot] PCIe driver for a new Freescale ARM64 SOC

[U-Boot] PCIe driver for a new Freescale ARM64 SOC

[Aurelian Floricica Voicu]

Hi!

I'm with Freescale and we are currently working on bringing up a ARM64
SOC platform.
The PCIe module is similar with the one used by the iMX family, being
a Synopsys IP.
However there are many differences in terms of the SOC integration
(clocking, pin muxing, control registers) plus an additional internal
DMA engine.
I would like to address a question about the U-Boot driver approach.
What would be an acceptable solution if we plan to make this driver
upstreamable :
1. Use existing pcie-imx.c driver and parameterize according to the
SOC platform
2. Create another driver file specific for the new family of SOCs
Thank you!

Aurelian Floricica

[U-Boot] PCIe driver for a new Freescale ARM64 SOC

[Albert ARIBAUD]

Hello Aurelian,

On Wed, 15 Jul 2015 12:33:04 +0000, Aurelian Floricica Voicu
<aurelian.floricica@freescale.com> wrote:
> Hi!
> 
> I'm with Freescale and we are currently working on bringing up a ARM64
> SOC platform.
> The PCIe module is similar with the one used by the iMX family, being
> a Synopsys IP.
> However there are many differences in terms of the SOC integration
> (clocking, pin muxing, control registers) plus an additional internal
> DMA engine.
> I would like to address a question about the U-Boot driver approach.
> What would be an acceptable solution if we plan to make this driver
> upstreamable :
> 1. Use existing pcie-imx.c driver and parameterize according to the
> SOC platform
> 2. Create another driver file specific for the new family of SOCs
> Thank you!

My .02 EUR:

Clocking and pinmuxing should be done in the board code, not in the
driver -- that's system integration, as you point out. The driver code
should simply assume that clocking and pinmuxing was done. If there is
a need for system-level functions, they can be passed to the driver at
init time, kept in function pointers an called back as ncessary.

Control registers -- depends. Do you mean tour version of the Synopsis
IP has registers and/or fields that the code does not know about? You
could put them under some xxxx_VERSION preprocessor macro so that your
board can define the macro and use the 'new' registers while 'older'
boards, which do not define the macro, would be protected from using
registers that don't exist for them.

In the end, it all boils down to how much of the current driver's code
would be common with the new driver. Lots of common code => single
driver, a few #if/#else/#endif. Otherwise, two drivers.

> Aurelian Floricica

Amicalement,
-- 
Albert.