Re: new utility kernel module for detecting cores in newer chipsets

[George Kashperko <george@znau.edu.ua>]

> 2011/3/21 Arend van Spriel <arend@broadcom.com>:
> > On Mon, 21 Mar 2011 15:27:49 +0100, Rafał Miłecki <zajec5@gmail.com> wrote:
> >
> >> The case is, we discussed ssb/ai driver layout few days ago. George
> >> shared idea of layout I agree with, nobody shared any objections. If
> >> everything goes fine, we should have nicely modularized driver/project
> >> supporting Broadcom's buses.
> >
> > Hi Rafał,
> >
> > Does this give us one module supporting both buses or does it provide two
> > kernel modules (my preference)? I did ask you and George this question
> > earlier but I seem to have missed the response from you or George.
> 
> I'm still waiting for George to respond and share his code.
> 
> 
> >> In this situation I'm not really interested is simple ai driver
> >> stripped from brcm80211. According to me, it would led to harder
> >> maintenance and harder implementation of support for such a driver in
> >> b43.
> >
> > I can imagine from b43 perspective the only good implementation would be to
> > stick with the current b43<->ssb interface. So what will you do when another
> > type of SoC interconnect is introduced. Forcing that in the same API as
> > well? If you and George propose a new carefully considered API covering the
> > functional capabilities of the current (and possibly future) interconnect
> > buses I am all for that.
> >
> > To summarize this, my main issue (and Michael's, I think) is with the
> > dependency being imposed between ai and ssb. Having two completely
> > independent modules really makes more sense.
> 
> This really depends on new interconnect. If it will be totally
> different, I'll vote for totally different driver. In case of SSB and
> AI, driver layout is similar, it seems George managed to write sth
> nice.
> 
> George?
Hi there. Much surprised with such a resonance on the topic. Sorry for
being so late with participating with discussion - work background
requires me sometimes to move around alot - this week is the time for
trips.
If you extremely hurry with that I will make my testings sources
available lately this evening as soon as get to my workpad. But just to
warn you its not that I planned for final "release" just glue I used to
work edge things out. As for final code I plan to finish with it next
weekends - yet again I will move al lot this week and will have much
time to think on the subject but not actually work on it.

Yet again sorry for making you wait.

Now back to subject. I curious about sertain things I see here which
make the most contradictary ones. That ones regarding why AI and SB
should be separate modules etc.
Would be much appreciated if you hear my mind on that (under hear I mean
not just read). Some time ago here in earlier AI rfcs' threads I already
tried to cover the reason why am I sure they should not just share
single code base but also be coupled together.
AI and SB interconnects are really totally diffeent hardware base. But
they stick to the single architecture model. Very much the same as PCI
and PCIE are (see what I'm trying to do here?). This model is not AI or
SB exclusive and in short looks like following (here I'm sorry for
making you read the things you know already, but I do it just because I
see that ones of you see on subject through Broadcom SDK while others do
the same through linux/ssb):
Bus devices coupled under the entity we tend to call cores. The cores
managed from the system bus side with means of the host. The cores
managed from the backplane side with means of agents. The core devices
exposed to system and managed with same drivers regardless the
backplane. The agents system dont supposted to know about and doing the
same enable/disable/reset but in somewhat different way. The fact is (as
at least I see it) that here we want to keep things apart just because
one set of agents is called SB (or e. g. PCI) while the other is called
AXI (or lets say PCIE).
Yes, linux/ssb model design can't cover this. The linux/bcmb (or hnd as
I finally named it - grrr really dont like these 3 letters -.-) might do
better as it is designed to do that. Btw in way which is completely
different from ssb and Broadcom SDK one.

Here much sorry need to get back to work. Will be back late in evening.

Have nice day,
George