public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] PCIe driver for a new Freescale ARM64 SOC
Date: Thu, 16 Jul 2015 19:31:16 +0200	[thread overview]
Message-ID: <20150716193116.6f533913@lilith> (raw)
In-Reply-To: <BL2PR03MB4204583B8EEE64792D93EFF889A0@BL2PR03MB420.namprd03.prod.outlook.com>

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.

      reply	other threads:[~2015-07-16 17:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15 12:33 [U-Boot] PCIe driver for a new Freescale ARM64 SOC Aurelian Floricica Voicu
2015-07-16 17:31 ` Albert ARIBAUD [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150716193116.6f533913@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox