AMBA devices behing a PCI bridge

AMBA devices behing a PCI bridge

[Alessandro Rubini]

Hello Russell.
I'm working, with some mates, on a device which is basically a bridge
from PCIe to AMBA.

Some of the peripherals that live behind the bridge are actually
normal primecell devices, with minor or no modifications from the
original ARM cores. The list includes dma, uart, spi, i2c and mmc.

The code that I received (on show at sta2x11.sourceforge.net) includes
several files that are almost exact copies of the respective amba
drivers in a pci enclosure. Then, the actual code includes a number of
other changes, but that's another issue that I'll attack later.

I don't like this code duplication and I don't think it is acceptable
upstream. So I tried to enable amba under arch/x86; in this way I
could write a simple PCI driver that registers one amba
device every time its probe function is called.  The ends meet and I
happily find my 4 serial ports registered in the system -- they are
not currently working: bugs are a fact of life and I'm working on it.

I'm confident this is the way to go for all the devices listed above.
If you agree with me, as ARM and AMBA maintainer, then I'd love to
have your opinion about how to address the following three issues.  I
currently just hacked stuff up to prove it works, but I can submit the
relevant patches for discussion and integration, if the idea is
accepted.

* CONFIG_ARM_AMBA: maybe it's high time to rename it to CONFIG_AMBA (
or CONFIG_PRIMECELL) like we have CONFIG_PCI, CONFIG_USB and a zillion
others? (I expect both the new and old config names to be accepted
for a while, to allow out-of-tree code to sync gracefully)

* <asm/sizes.h>: most of the amba world uses this header. Maybe it should
be turned into <linux/sizes.h>, since it has nothing arch-specific in it?
(you may remember I removed the inclusion from amba/bus.c, but that's
not enough as most amba code uses the header anyways).

* Not all archs use the clk API. Currently I copied over the empty
definitions found in arch/m68k/platform/coldfire/clk.c into
arch/x86/platform/sta2x11/clk.c . Maybe we should offer weak empty
definition for those functions? Or should the clk world be ported to x86
and other architectures? (the latter I can't do by myself, I'm sorry).

/alessandro

AMBA devices behing a PCI bridge

[Russell King - ARM Linux]

On Wed, Feb 22, 2012 at 08:13:39PM +0100, Alessandro Rubini wrote:
> * CONFIG_ARM_AMBA: maybe it's high time to rename it to CONFIG_AMBA (
> or CONFIG_PRIMECELL) like we have CONFIG_PCI, CONFIG_USB and a zillion
> others? (I expect both the new and old config names to be accepted
> for a while, to allow out-of-tree code to sync gracefully)

It has 'ARM' in it to signify the manufacturer who holes the base
specification for the bus.  Rather than just have 'AMBA' which could
get confusing if someone decides to call something they have 'AMBA'
too.

The only change I'd suggest is CONFIG_ARM_PRIMECELL because it's really
about primecells, not about AMBA peripherals.  Primecells are a sub-class
of AMBA peripherals.

> * <asm/sizes.h>: most of the amba world uses this header. Maybe it should
> be turned into <linux/sizes.h>, since it has nothing arch-specific in it?
> (you may remember I removed the inclusion from amba/bus.c, but that's
> not enough as most amba code uses the header anyways).

It's already asm-generic/sizes.h, and I'd suggest just moving that to
linux/sizes.h and be done about it.

> * Not all archs use the clk API. Currently I copied over the empty
> definitions found in arch/m68k/platform/coldfire/clk.c into
> arch/x86/platform/sta2x11/clk.c . Maybe we should offer weak empty
> definition for those functions? Or should the clk world be ported to x86
> and other architectures? (the latter I can't do by myself, I'm sorry).

Well, there's an effort to provide a unified clk API, which has been in
progress for a couple of years.  It's getting closer, so it may not be
too long before this problem is solved.

But yes, the clk API is fundamental to these drivers because of their
portability - that's precisely why the clk API was provided, so that
these exact drivers did not have to end up with a forever growing pile
of platform specific junk being ifdef'd into them (and that's exactly
what would've happened as every platform supplies different clock rates
and has different ways to control their clocks.)

So yes, the answer is to provide the clk API rather than trying to
bugger the drivers to work without it.  I'd suggest waiting for the
unified clk API to be merged first though, otherwise there'll be
yet another implementation in need of conversion effort.

AMBA devices behing a PCI bridge

[Linus Walleij]

On Wed, Feb 22, 2012 at 8:13 PM, Alessandro Rubini <ru@gnudd.com> wrote:

> Hello Russell.
> I'm working, with some mates, on a device which is basically a bridge
> from PCIe to AMBA.
>
> Some of the peripherals that live behind the bridge are actually
> normal primecell devices, with minor or no modifications from the
> original ARM cores. The list includes dma, uart, spi, i2c and mmc.

Just watching from the side this is very interesting, and of course it is
wise to reuse the existing PrimeCell drivers, given the effort that has
been put into maintaining and generalizing them over the last few
years.

Thanks for looking into this and I'll be happy to help out with the
review!

Yours,
Linus Walleij