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

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

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 :
- 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,
participants (2)
-
Albert ARIBAUD
-
Aurelian Floricica Voicu