[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1302726187.7911.11.camel@dev.znau.edu.ua>
Date: Wed, 13 Apr 2011 23:23:07 +0300
From: George Kashperko <george@...u.edu.ua>
To: Rafał Miłecki <zajec5@...il.com>
Cc: Arend van Spriel <arend@...adcom.com>,
"balbi@...com" <balbi@...com>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"John W. Linville" <linville@...driver.com>,
"b43-dev@...ts.infradead.org" <b43-dev@...ts.infradead.org>,
Michael Büsch <mb@...sch.de>,
Larry Finger <Larry.Finger@...inger.net>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Russell King <rmk@....linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
Andy Botting <andy@...ybotting.com>,
linuxdriverproject <devel@...uxdriverproject.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] axi: add AXI bus driver
> 2011/4/13 Arend van Spriel <arend@...adcom.com>:
> > On Tue, 12 Apr 2011 22:44:01 +0200, Rafał Miłecki <zajec5@...il.com> wrote:
> >
> >> 2011/4/12 George Kashperko <george@...u.edu.ua>:
> >>>>
> >>>> 2011/4/12 Rafał Miłecki <zajec5@...il.com>:
> >>>> That way I see really low (or not at all) relation between out
> >>>> (not)Broadcom bus and present AMBA bus.
> >>>>
> >>> Agree.
> >>
> >> Ehh, sounds like one more renaming to functions, defines, prefixes.
> >>
> >> Let's wait for Arend comments, he was the one voting for not-bcm-specific
> >> name.
> >>
> >
> > Hi Rafał,
> >
> > Still think its better to stick with a generic name even if currently you
> > only come across this in Broadcom chips right now. I do agree that the term
> > 'axi' is implying something else than what this bus driver is providing. The
> > name 'axi-dmp' I gave earlier may be more to the point.
> >
> > I also looked at the amba driver after receiving comments on the brcmaxi
> > library module (this is what Hauke Mehrtens referred to) and came to similar
> > conclusion as you did. It does however support PM properly so you may want
> > to get inspiration in that area. I also noticed a reference to AMBA term APB
> > which is a different bus in the AMBA family. AXI was introduced later as
> > higher performance bus (in AMBA rev3 if I remember correctly).
>
> I don't focus on PM yet, do not consider it a problem, it just needs some time.
>
> Note for not involved: AMBA is family with few buses/interfaces
> possible: AXI, AHB, ASB, APB, ATB [1].
>
> So what are you saying is that drivers/amba/ is for AMBA APB? OK, I
> can accept such a explanation and it makes me even more sure we need
> another AMBA driver (this time: AMBA AXI).
AMBA is AMBA. axi/apb/ahb etc are all subsets of AMBA and as of current
all fit to what already is in drivers/amba.
>
> The left question is: how much of the implemented code is AMBA AXI
> specific and how much is Broadcom specific?
Answers to 1. and 2. are there in drivers/amba/bus.c
Look _probe and _register fn for more details.
> 1) Does AMBA AXI identify cores by manuf, id, rev and class? Is this
> really AMBA AXI specific and a evolution from simple "id" in AMBA APB?
During amba device registration amba bus code read component/peripheral
id registers from known locations, exactly where
peripherialid/componentid registers of master port (agent) core are.
Look brcm80211/inclue/aidmp.h for those.
> 2) Is this standard for AMBA AXI to keep list of available cores in
> some specific memory (is this always EPROM like in case of Bcm?)?
> 3) Does every AMBA AXI device need enabling/disabling/resetting
> routine we implemented? Is that really Bcm independent?
Enable/disable abstracted by clocks interface.
It would be really great if someone could enligten us on 2).
> This is mostly what I already asked, but didn't get answer. Please,
> explain to us what is AMBA AXI specific and what is Broadcom specific.
>
> [1] http://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture
>
Have nice day,
George
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists