[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTik6JZ-n3sVjCFK_x1yNRH3_o3_6rg@mail.gmail.com>
Date: Wed, 13 Apr 2011 21:50:36 +0200
From: Rafał Miłecki <zajec5@...il.com>
To: Arend van Spriel <arend@...adcom.com>
Cc: George Kashperko <george@...u.edu.ua>,
"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).
The left question is: how much of the implemented code is AMBA AXI
specific and how much is Broadcom specific?
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?
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?
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
--
Rafał
--
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