Thread (47 messages) 47 messages, 8 authors, 2011-06-11

Re: [RFC][PATCH 01/10] bcma: Use array to store cores.

From: Rafał Miłecki <zajec5@gmail.com>
Date: 2011-06-08 00:06:20
Also in: linux-mips

2011/6/7 Hauke Mehrtens [off-list ref]:
On 06/07/2011 12:12 PM, Arend van Spriel wrote:
quoted
On 06/06/2011 11:53 PM, Arnd Bergmann wrote:
quoted
On Monday 06 June 2011 23:38:50 Hauke Mehrtens wrote:
quoted
Accessing chip common should be possible without scanning the hole bus
as it is at the first position and initializing most things just needs
chip common. For initializing the interrupts scanning is needed as we do
not know where the mips core is located.

As we can not use kalloc on early boot we could use a function which
uses kalloc under normal conditions and when on early boot the
architecture code which starts the bcma code should also provide a
function which returns a pointer to some memory in its text segment to
use. We need space for 16 cores in the architecture code.

In addition bcma_bus_register(struct bcma_bus *bus) has to be divided
into two parts. The first part will scan the bus and initialize chip
common and mips core. The second part will initialize pci core and
register the devices in the system. When using this under normal
conditions they will be called directly after each other.
Just split out the minimal low-level function from the bcma_bus_scan
then, to locate a single device based on some identifier. The
bcma_bus_scan() function can then repeatedly allocate one device
and pass it to the low-level function when doing the proper scan,
while the arch code calls the low-level function directly with static
data.
If going for this we should pass struct bcma_device_id as match
parameter as that identifies the core appropriately although you
probably only want to match manufacturer and core identifiers.

Gr. AvS
What is the problem with scanning the full bus?
Because full scanning needs one of the following:
1) Working alloc - not possible for SoCs
2) Hacks with wrappers, static cores info, lack of optimization (list)

A special scan function would just skip the wrong cores so I do not see
any advantage in that.

We could build a scan function which searches for one core and uses a
struct bcma_core stored on the stack and returns the struct bcma_core if
it found the wanted one.
Yeah, this should be quite easy.

struct bcma_device core = bcma_early_find_core(bus, CC);
bcma_cc_init(core);

Then we could search for chipcommon and mips
and store then in arch code in arch/mips/bcm47xx and use them.
Not sure about this one. You have drivers for chipcommon and mips as
part of bcma. Do you need to involve arch/mips/bcm47xx to this?

When boot
is ready and we are searching the complete bus there is probably
something differences in the init process from normal init as we already
initialized chipcommon sometime earlier.
Nothing hard to handle.

I Would prefer to scan the bus
completely and initialize chipcommon and mips in early boot.
Really, I've nothing against scanning and splitting init into "early"
and "late". It's going back to static fields and wrappers that I don't
like :(

-- 
Rafał
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help