[BHND SoC] Add BHND SoC support (only BCMA case)

[mizhka]

Summary

This patch introduce to add support of BHND on SoC: nexus-to-bhnd drivers.

bhnd_soc is attached under nexus and responsible for all BHND-style calls from BHND(4) bus to parents.
bcma_nexus is BHND(4) bus, attached to bhnd_soc and implement all nexus-style behaviour of BHND.

[mizhka]

• small changes after rebase to today's head

[landon_landonf.org]

It should be possible to unify these as a single bcma_nexus driver that attaches to the mips nexus, and rely on the default/inherited implementation for most of these methods.

In the case of BHND_BUS_IS_HW_DISABLED, the default null implementation will be a problem (it panic()s); you could modify it to return false instead.

I should be able to run this locally on a MIPS device in the next couple days, at which point I can also help take a look at any issues in bhnd.

[mizhka]

In D6248#134084, @landon_landonf.org wrote:

It should be possible to unify these as a single bcma_nexus driver that attaches to the mips nexus, and rely on the default/inherited implementation for most of these methods.

In the case of BHND_BUS_IS_HW_DISABLED, the default null implementation will be a problem (it panic()s); you could modify it to return false instead.

I should be able to run this locally on a MIPS device in the next couple days, at which point I can also help take a look at any issues in bhnd.

Default BHND resource activation is also good topic for discussion. Now it's call propagation to parent and fail if no parent. To avoid bhnd_soc, it also requires change.

BHND bus (bcma or siba) fetches CHIP ID from parent, so default get_chipid shouldn't panic and returns CHIP ID by calling bhnd_read_chipid.

Another question is resource allocation, BHND bus allocates resources for all cores (future devices). It may be done via hints, but it's not nice because BHND can handle up to 16 cores (or may be more) and it results in 16*3 lines of hints.

What is benefit of direct attachment of bcma_nexus to mips nexus?

[landon_landonf.org]

In D6248#134154, @mizhka_gmail.com wrote:

In D6248#134084, @landon_landonf.org wrote:

It should be possible to unify these as a single bcma_nexus driver that attaches to the mips nexus, and rely on the default/inherited implementation for most of these methods.

In the case of BHND_BUS_IS_HW_DISABLED, the default null implementation will be a problem (it panic()s); you could modify it to return false instead.

I should be able to run this locally on a MIPS device in the next couple days, at which point I can also help take a look at any issues in bhnd.

Default BHND resource activation is also good topic for discussion. Now it's call propagation to parent and fail if no parent. To avoid bhnd_soc, it also requires change.

Right. Just to be explicit about it:

• The default implementation of bhnd_bus_generic_alloc_resource delegates to BUS_ALLOC_RESOURCE and BHND_BUS_ACTIVATE_RESOURCE.
• The default implementation of bhnd_bus_generic_activate_resource tries to delegate to the parent bus. If none, it returns EINVAL.

It should be sufficient to implement the standard BUS_ALLOC_RESOURCE, and the bhnd(4)-specific BHND_BUS_ACTIVATE_RESOURCE(), and have bhnd_bus_activate_resource just delegate to BUS_ACTIVATE_RESOURCE.

We could add a bhnd_bus_generic_direct_activate_resource() method implementation to bhnd_subr.c that provided this.

BHND bus (bcma or siba) fetches CHIP ID from parent, so default get_chipid shouldn't panic and returns CHIP ID by calling bhnd_read_chipid.

Since the location of ChipCommon can in theory vary (and some early siba(4) devices don't have a ChipCommon core), this behavior (and thus, the top-level bhnd drivers) would still need to be specific to the root bus being used:

• On a platform using a root 'nexus' bus, my understanding is that the basic configuration (including the base ChipCommon address) should generally be fetched via device hints (ex sys/mips/conf/SENTRY5.hints).
• On a platform using FDT, the device tree will supply the address of the chipcommon register block, and possibly interrupt configuration, etc.
• On bridged PCI/SDIO/etc devices, a custom bhndb_* driver handles the device-specific behavior, and the bcma_bhndb/siba_bhndb drivers delegate most of this to bhndb.

Another question is resource allocation, BHND bus allocates resources for all cores (future devices). It may be done via hints, but it's not nice because BHND can handle up to 16 cores (or may be more) and it results in 16*3 lines of hints.

You should be able to to safely do this lazily; the MIPS nexus implementation will allocate/activate resources for devices that are children of the actual nexus-attached device -- you'd just need to check for RMAN_IS_DEFAULT_RANGE(start, end) && count == 1 and populate the request with default values before delegating to the parent nexus (and/or consult a local rman if you have one).

For an example of this (@adrian or @sobomax might have a better one), check out siba_alloc_resource() in sys/dev/siba/siba_mips.c.

What is benefit of direct attachment of bcma_nexus to mips nexus?

Just fewer moving parts. If there's common behavior we want bcma_nexus to inherit, we can reference common functions implementing the methods, or use kobj's inheritance mechanisms, without needing a full intermediary bhnd_soc parent in the device tree.

[mizhka]

• early bus passing