[Top] [All Lists]

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

To: Hauke Mehrtens <>
Subject: Re: [RFC][PATCH 01/10] bcma: Use array to store cores.
From: Rafał Miłecki <>
Date: Wed, 8 Jun 2011 02:06:11 +0200
Cc: Arend van Spriel <>, Arnd Bergmann <>, George Kashperko <>, Greg KH <>, "" <>, "" <>, "" <>, "" <>, "" <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K+Z40NT6khlEY56HN+YhQYngCQXk2G3BTYBEW4PB1ss=; b=THxuYTE3GBQleFI2pZPgegGtkkp0vBvlwtYisUKSCzc/+rmJoh0nCY2p4rBpRY9Uvy D1d02rzqFtJTLhqEztxKI3CqPVKhOVmhVSOtobXomKkFkKxAd/XBNVz7m7zVFgbQvmLd 38xR+zT1hgj1sXqdGo3haNR3Agqr0qGwR2pzU=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CQHF0TQBzPanR3RyPoCzYAMnUhQp8e47waZQwnLyo0HkJEFGkVFWwTtmBpgdFAuXxU w74AcVbOlorljQvCkSwWWXzHHUs0c3c9YanNvEFCLxSlSZC33GoUueN9vVgYmPAvU/M/ MjgAKJ+XolDj+MiLTicC74rHCL/DDCbSOyBHA=
In-reply-to: <>
References: <> <> <> <> <> <>
2011/6/7 Hauke Mehrtens <>:
> On 06/07/2011 12:12 PM, Arend van Spriel wrote:
>> On 06/06/2011 11:53 PM, Arnd Bergmann wrote:
>>> On Monday 06 June 2011 23:38:50 Hauke Mehrtens wrote:
>>>> 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);

> 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 :(


<Prev in Thread] Current Thread [Next in Thread>