Arrgh.... Tired to hell but can't sleep...
So im back ! ;)
> On Thu, 2011-02-10 at 20:24 +0200, George Kashperko wrote:
> > > code in drivers. Let's call it "hndbackplane" or something like that.
> > hndbackplane... nevah!!1 :p Since some time I started hating hnd abbreviation dunno why.
>
> Well, it's just a name I made up right now.
> It obviously is not a good one. ;)
> It was just my way to explain the idea of a thin layer between
> SSB (or AI) and drivers. That thin layer can be a mostly-inline function
> layer with if()..else or a function table layer.
Yes, I got your idea. But to be honest the more I think about actual
implementation the more I beleive mine initial proposal is less
intrusive one but might need to be redesigned slightly to avoid
confusion with original SSB and guarantee proper support with hosted AI
later on.
Anyway as I've already said I'm going to take a break for few days to
plan things with separate bus driver. Its not like I gave up and will
start on bus code right away. Just want to see the whole picture. As
soon as I finish with my paintings and if only I see at least 1ne more
advantage for separate bus driver rather than ssb+ai driver I will start
with this way ofcourse.
But yet again not like im scared of amount of if/else stuff this will
introduce (most of it could be hidden with proper inliners anyway). Just
looks like AI bus driver is either to replicate the whole ssb_bus struct
layout or whole ssb-based code subset with device drivers as well will
be flooded with those if/else or inline ssb_gimme_bus(). Replicating (or
including in first place) the whole ssb_bus makes me think AI is much
more SSB than just AI, while all those if/else even inlined look for me
less desirable and clean than ssb_core_(ctl|state)_flags. Wrapping
required ssb codebase with some bcmai_zzz() will require ssb_bus struct
replication yet again. There might be some other way I dont see atm,
hopefully I will after get some rest.
> > Any chance someone can share alike .pdf for AI socs ?
>
> I think that's pretty much the only one available.
> Broadcom doesn't really distribute docs on HND, but only code.
Maybe some kind Broadcom guy could comment on this ? -.-
Might not, but I was to try anyway.
> > Also would be much
> > appreciated if you could help me with finding out non-embedded bcm
> > ai-based hw part-numbers.
>
> I have no idea. You could probably look at brcm80211 for starters?
>
Already done with that, unfortunately PCI_VENDOR_ID_BROADCOM with
dev_ids 0x4357/0x4353/0x4727 gives me no clue if they are SB or AI
based. Must back again dig deep into bcm80211 but I'm already tired to
hell with all those sih, sii and osh stuff :/
Have nice day,
George
On Thu, 2011-02-10 at 21:52 +0200, George Kashperko wrote:
> But yet again not like im scared of amount of if/else stuff this will
> introduce (most of it could be hidden with proper inliners anyway). Just
I don't think the amount of conditionals will be much bigger than the
amount in your current approach. Especially not if you use ops.
> > I have no idea. You could probably look at brcm80211 for starters?
> >
> Already done with that, unfortunately PCI_VENDOR_ID_BROADCOM with
> dev_ids 0x4357/0x4353/0x4727 gives me no clue if they are SB or AI
> based.
They are all AI based.
--
Greetings Michael.