linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hauke Mehrtens <hauke@hauke-m.de>
To: Arend van Spriel <arend@broadcom.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	"George Kashperko" <george@znau.edu.ua>,
	"Rafał Miłecki" <zajec5@gmail.com>, "Greg KH" <greg@kroah.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"mb@bu3sch.de" <mb@bu3sch.de>,
	"b43-dev@lists.infradead.org" <b43-dev@lists.infradead.org>,
	"bernhardloos@googlemail.com" <bernhardloos@googlemail.com>
Subject: Re: [RFC][PATCH 01/10] bcma: Use array to store cores.
Date: Tue, 07 Jun 2011 23:44:45 +0200	[thread overview]
Message-ID: <4DEE9BCD.1030304@hauke-m.de> (raw)
In-Reply-To: <4DEDF98C.6020905@broadcom.com>

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? Scanning in general
works for embedded devices, just allocating memory with kalloc does not
work at that time, but the architecture code (something in
arch/mips/bcm47xx/) could provide some memory to store the struct
bcma_core, like it does for struct bcma_bus. We could just provide
memory for chipcommon and mips core or memory for all possible 16 cores,
the maximum number, as most embedded devices have ~9 cores providing
memory for 16 cores is not a big vast of memory and then we could use
the normal scan function.

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. Then we could search for chipcommon and mips
and store then in arch code in arch/mips/bcm47xx and use them. 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. I Would prefer to scan the bus
completely and initialize chipcommon and mips in early boot.

Hauke

  reply	other threads:[~2011-06-07 21:44 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-05 22:07 [RFC][PATCH 00/10] bcma: add support for embedded devices like bcm4716 Hauke Mehrtens
2011-06-05 22:07 ` [RFC][PATCH 01/10] bcma: Use array to store cores Hauke Mehrtens
2011-06-06  8:31   ` Arend van Spriel
2011-06-06  9:42   ` Rafał Miłecki
2011-06-06 10:09     ` Arend van Spriel
2011-06-06 11:32     ` Arnd Bergmann
2011-06-06 12:29       ` George Kashperko
2011-06-06 13:03         ` Arnd Bergmann
2011-06-06 21:38           ` Hauke Mehrtens
2011-06-06 21:53             ` Arnd Bergmann
2011-06-07 10:12               ` Arend van Spriel
2011-06-07 21:44                 ` Hauke Mehrtens [this message]
2011-06-08  0:06                   ` Rafał Miłecki
2011-06-08  8:20                     ` Michael Büsch
2011-06-11 22:33                       ` Hauke Mehrtens
2011-06-05 22:07 ` [RFC][PATCH 02/10] bcma: Make it possible to run bcma_register_cores() later Hauke Mehrtens
2011-06-05 22:07 ` [RFC][PATCH 03/10] bcma: add embedded bus Hauke Mehrtens
2011-06-05 23:22   ` Julian Calaby
2011-06-06 21:40     ` Hauke Mehrtens
2011-06-06 10:22   ` Rafał Miłecki
2011-06-06 10:32     ` George Kashperko
2011-06-06 10:51       ` Rafał Miłecki
2011-06-06 10:55         ` Arend van Spriel
2011-06-06 11:00           ` Rafał Miłecki
2011-06-06 22:00     ` Hauke Mehrtens
2011-06-07  0:33       ` Rafał Miłecki
2011-06-07 10:30         ` Arend van Spriel
2011-06-07 21:23           ` Hauke Mehrtens
2011-06-05 22:07 ` [RFC][PATCH 04/10] bcma: add mips driver Hauke Mehrtens
2011-06-06 11:23   ` Rafał Miłecki
2011-06-06 22:06     ` Hauke Mehrtens
2011-06-06 22:50       ` Rafał Miłecki
2011-06-05 22:07 ` [RFC][PATCH 05/10] bcma: add serial console support Hauke Mehrtens
2011-06-06 10:30   ` Rafał Miłecki
2011-06-05 22:07 ` [RFC][PATCH 06/10] bcma: get CPU clock Hauke Mehrtens
2011-06-06 10:34   ` Rafał Miłecki
2011-06-06 10:40     ` Rafał Miłecki
2011-06-05 22:07 ` [RFC][PATCH 07/10] bcma: add pci(e) host mode Hauke Mehrtens
2011-06-06 11:32   ` Rafał Miłecki
2011-06-06 22:11     ` Hauke Mehrtens
2011-06-06 11:34   ` Rafał Miłecki
2011-06-05 22:07 ` [RFC][PATCH 08/10] bcm47xx: prepare to support different buses Hauke Mehrtens
2011-06-05 22:07 ` [RFC][PATCH 09/10] bcm47xx: add support for bcma bus Hauke Mehrtens
2011-06-06 11:07   ` Rafał Miłecki
2011-06-06 22:13     ` Hauke Mehrtens
2011-06-05 22:07 ` [RFC][PATCH 10/10] bcm47xx: fix irq assignment for new SoCs Hauke Mehrtens
2011-06-06  9:24   ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DEE9BCD.1030304@hauke-m.de \
    --to=hauke@hauke-m.de \
    --cc=arend@broadcom.com \
    --cc=arnd@arndb.de \
    --cc=b43-dev@lists.infradead.org \
    --cc=bernhardloos@googlemail.com \
    --cc=george@znau.edu.ua \
    --cc=greg@kroah.com \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).