[PATCH 0/1] new module for amba axi on-chip interconnect

[PATCH 0/1] new module for amba axi on-chip interconnect

[Arnd Bergmann]

On Tuesday 29 March 2011, Russell King wrote:
> On Tue, Mar 29, 2011 at 11:40:18AM +0200, Arend van Spriel wrote:
> > GUIDANCE NEEDED:
> > This patch puts the module at proposed location. Please provide your
> > guidance if there is a better location within the linux tree for this
> > module.
> > 
> > This module has been isolated from the brcm80211 driver currently
> > located in staging and provided to other drivers for chipsets using
> > the AMBA AXI on-chip interconnect with ARM Device Management Plugin
> > (DMP) silicon IP, which provides system discovery (chip being the
> > system) and basic core function (disable, reset, etc.).
> 
> What does this do which the 'amba' bus support doesn't?

I believe the one thing we really want from this driver is the bus
scan code, which is not present in the amba bus implementation,
as far as I can tell. Today, the amba bus does very little beyond
what the platform bus does, in particular you still need to
register every single device from board specific code.

When the proposed axi_scan() function gets turned into an
amba_bus_register() function, a board file can call that to
add all devices on the bus without listing them individually
and calling amba_device_register() for each one.

Basically everything else is already there in the amba bus,
no need to do it again.

	Arnd

[PATCH 0/1] new module for amba axi on-chip interconnect

[Russell King - ARM Linux]

On Wed, Mar 30, 2011 at 03:09:04PM +0200, Arnd Bergmann wrote:
> I believe the one thing we really want from this driver is the bus
> scan code, which is not present in the amba bus implementation,
> as far as I can tell. Today, the amba bus does very little beyond
> what the platform bus does, in particular you still need to
> register every single device from board specific code.
> 
> When the proposed axi_scan() function gets turned into an
> amba_bus_register() function, a board file can call that to
> add all devices on the bus without listing them individually
> and calling amba_device_register() for each one.
> 
> Basically everything else is already there in the amba bus,
> no need to do it again.

The reason we don't do automatic scanning (which we could on the various
ARM platforms) is because of the platform data necessary to make some of
the primecell drivers work.

Unfortunately, these buses are not as simple as PCI, where a device
typically sits on its own card and is totally self-contained.  With
primecell stuff, there's normally some interdependencies between the
various primecells.

That doesn't stop there being an automatic enumeration layer, but such
a layer would need some way of attaching platform specific data to
specific amba devices.

[PATCH 0/1] new module for amba axi on-chip interconnect

[Arnd Bergmann]

On Wednesday 30 March 2011 19:40:10 Russell King - ARM Linux wrote:

> The reason we don't do automatic scanning (which we could on the various
> ARM platforms) is because of the platform data necessary to make some of
> the primecell drivers work.
> 
> Unfortunately, these buses are not as simple as PCI, where a device
> typically sits on its own card and is totally self-contained.  With
> primecell stuff, there's normally some interdependencies between the
> various primecells.
> 
> That doesn't stop there being an automatic enumeration layer, but such
> a layer would need some way of attaching platform specific data to
> specific amba devices.

Right, I understand that this would not completely remove the need for
platform devices, but I think it would be a great step in the right
direction if we could scan all simple devices automatically, or
possibly even all devices in some simple machines.

If we can scan the main resources (memory ranges, interrupts, ...),
that will make it possible to avoid a whole lot of the stuff we currently
do for each new board. It also means we can gradually move away from
statically defined devices, something that Greg has been pushing for
quite some time.

The device tree work has shown that it's possible to describe very
complex hardware in simple data structures, but it would be much
better if we needed neither a device tree nor a board file for this.
As you say, this isn't possible today with the data on available
to the AMBA bus, but I think it would be better to just fill in 
the blanks (and corrections where they are wrong) than to duplicate
all of it as we now do in the kernel.

Ideally, we would point SoC companies to this (or a future extended
version) as the place to add all the required information when
they want the drivers to work out of the box. My impression is that
there is no fundamental difference to buses like PCI or USB, other
than that there is more data required to encode and that there is
a lack of social pressure to get it right. I remember PCI cards
from the 1990s that could not be probed properly and required
setting a lot of module parameters copied from a web site depending
on what hardware you had bought. The reason we don't have that 
as much today is that the manufacturers realized that it's impossible
to write proper drivers if you cannot detect the hardware.

	Arnd

[PATCH 0/1] new module for amba axi on-chip interconnect

[Russell King - ARM Linux]

On Wed, Mar 30, 2011 at 08:24:49PM +0200, Arnd Bergmann wrote:
> On Wednesday 30 March 2011 19:40:10 Russell King - ARM Linux wrote:
> 
> > The reason we don't do automatic scanning (which we could on the various
> > ARM platforms) is because of the platform data necessary to make some of
> > the primecell drivers work.
> > 
> > Unfortunately, these buses are not as simple as PCI, where a device
> > typically sits on its own card and is totally self-contained.  With
> > primecell stuff, there's normally some interdependencies between the
> > various primecells.
> > 
> > That doesn't stop there being an automatic enumeration layer, but such
> > a layer would need some way of attaching platform specific data to
> > specific amba devices.
> 
> Right, I understand that this would not completely remove the need for
> platform devices, but I think it would be a great step in the right
> direction if we could scan all simple devices automatically, or
> possibly even all devices in some simple machines.

I'm not talking about platform devices at all.  I'm talking about the data
which platforms need to supply to their drivers in order for the drivers
to work.

Eg, how the DMA is connected (or indeed whether the DMA signals are even
connected in the first place).  Where the card detect signal is for the
MMC slot for the particular controller we've found, etc.

It's not as simple as (eg) detecting a MMC controller and immediately
pointing it at the GPIO number - the "simple" ARM dev platforms normally
have two MMC controllers so that needs to be distinguished.

This kind of data is precisely why I went down the static declaration
route for all ARM dev platforms, despite most devices being trivially
discoverable.  I couldn't work out a decent way to automatically scan
the devices while ensuring that the right platform specific driver data
was attached to its correct device.

> The device tree work has shown that it's possible to describe very
> complex hardware in simple data structures, but it would be much
> better if we needed neither a device tree nor a board file for this.

The device tree goes against automatic device discovery - unless you
have a shim which runs before the kernel executes to adjust the device
tree appropriately.  Otherwise, I can't see anyway you could cope with
(eg) a platform having MMC controllers at 0x10004000 and 0x10008000,
and another with just one MMC controller at 0x10008000 but using the
card detect lines from 0x10004000.

> I remember PCI cards
> from the 1990s that could not be probed properly and required
> setting a lot of module parameters copied from a web site depending
> on what hardware you had bought. The reason we don't have that 
> as much today is that the manufacturers realized that it's impossible
> to write proper drivers if you cannot detect the hardware.

I think you're going to be waiting a very long time for that to happen.
No SoC vendor adds device IDs to their on-chip devices to allow them to
be automatically discovered - it's only through ARM Ltd's development of
their Primecells, and then vendors integrating those into their SoC (maybe
with their own modifications) that we've started to see this kind of ID
system appearing.

Outside of the Primecell stuff, I'm unaware of anyone adding any kind
of discovery mechanism to SoC based devices.

So, all in all I don't think that the automatic discovery idea is worth
the effort.  All that I can see is it causing lots of problems.

[PATCH 0/1] new module for amba axi on-chip interconnect

[Arend van Spriel]

On Wednesday 30 March 2011 20:08:57 +0100 Russell King - ARM Linux wrote:
> I think you're going to be waiting a very long time for that to happen.
> No SoC vendor adds device IDs to their on-chip devices to allow them to
> be automatically discovered - it's only through ARM Ltd's development of
> their Primecells, and then vendors integrating those into their SoC  
> (maybe
> with their own modifications) that we've started to see this kind of ID
> system appearing.

Actually, Broadcom does. ARM delivers the DMP plugin. This adds additional  
register space with each core and each core is identified with a vendor id  
(maintained by JEDEC to assure it is unique), a core id, and a core class.  
Another used interconnect is SSB which also offers discovery functionality.

> Outside of the Primecell stuff, I'm unaware of anyone adding any kind
> of discovery mechanism to SoC based devices.

Not sure either.

Gr. AvS
-- 
"The most merciful thing in the world, I think, is the inability of the  
human
mind to correlate all its contents." - "The Call of Cthulhu"

[PATCH 0/1] new module for amba axi on-chip interconnect

[Arnd Bergmann]

On Wednesday 30 March 2011, Russell King - ARM Linux wrote:
> On Wed, Mar 30, 2011 at 08:24:49PM +0200, Arnd Bergmann wrote:
> > On Wednesday 30 March 2011 19:40:10 Russell King - ARM Linux wrote:
> > 
> > > The reason we don't do automatic scanning (which we could on the various
> > > ARM platforms) is because of the platform data necessary to make some of
> > > the primecell drivers work.
> > > 
> > > Unfortunately, these buses are not as simple as PCI, where a device
> > > typically sits on its own card and is totally self-contained.  With
> > > primecell stuff, there's normally some interdependencies between the
> > > various primecells.
> > > 
> > > That doesn't stop there being an automatic enumeration layer, but such
> > > a layer would need some way of attaching platform specific data to
> > > specific amba devices.
> > 
> > Right, I understand that this would not completely remove the need for
> > platform devices, but I think it would be a great step in the right
> > direction if we could scan all simple devices automatically, or
> > possibly even all devices in some simple machines.
> 
> I'm not talking about platform devices at all.  I'm talking about the data
> which platforms need to supply to their drivers in order for the drivers
> to work.

Yes, I meant platform_data, not platform_device.

> This kind of data is precisely why I went down the static declaration
> route for all ARM dev platforms, despite most devices being trivially
> discoverable.  I couldn't work out a decent way to automatically scan
> the devices while ensuring that the right platform specific driver data
> was attached to its correct device.

Maybe we can look at this again. The device tree scanning code 
is able to connect properties from the device tree to e.g. PCI
devices that are probed from hardware. It may not be easy to
do, but my feeling is that there is a lot to gain if we manage
to do it.
 
> > The device tree work has shown that it's possible to describe very
> > complex hardware in simple data structures, but it would be much
> > better if we needed neither a device tree nor a board file for this.
> 
> The device tree goes against automatic device discovery - unless you
> have a shim which runs before the kernel executes to adjust the device
> tree appropriately.  Otherwise, I can't see anyway you could cope with
> (eg) a platform having MMC controllers at 0x10004000 and 0x10008000,
> and another with just one MMC controller at 0x10008000 but using the
> card detect lines from 0x10004000.

The device tree is just another way to do automatic device discovery.
Fundamentally there is not much difference between reading data in
a fixed format from a PCI config space, a hardware ROM on AMBA or
a blob passed into the kernel.

The disadvantage of the device tree is that it's harder to get it
to match the actual hardware, while the advantage is that it's
flexible enough to describe the example you just gave.

As I mentioned above, it's possible to describe devices in the
device tree format that are also detected from hardware
scanning, and to combine information from both sources.

If the information in the hardware is complete, as is usually
the case on PCI or USB buses, the device trees we use on other
architectures only list the root node of a bus that gets scanned
in hardware.

> > I remember PCI cards
> > from the 1990s that could not be probed properly and required
> > setting a lot of module parameters copied from a web site depending
> > on what hardware you had bought. The reason we don't have that 
> > as much today is that the manufacturers realized that it's impossible
> > to write proper drivers if you cannot detect the hardware.
> 
> I think you're going to be waiting a very long time for that to happen.
> No SoC vendor adds device IDs to their on-chip devices to allow them to
> be automatically discovered - it's only through ARM Ltd's development of
> their Primecells, and then vendors integrating those into their SoC (maybe
> with their own modifications) that we've started to see this kind of ID
> system appearing.
> 
> Outside of the Primecell stuff, I'm unaware of anyone adding any kind
> of discovery mechanism to SoC based devices.

I'm willing to try to keep pushing for it, once I figure out where ;-)

If we have support for automatic probing of some devices in the kernel,
that might be a way to convince hardware vendors that simply putting
correct information in the hardware can improve their time to market,
which directly translates into money.

	Arnd