linux-kernel - Re: [RFC][PATCH] axi: add AXI bus driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTi=8HEysFXhcv5yn=ErWZkzzqPoSug@mail.gmail.com>
Date:	Wed, 13 Apr 2011 23:05:51 +0200
From:	Rafał Miłecki <zajec5@...il.com>
To:	George Kashperko <george@...u.edu.ua>
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 George Kashperko <george@...u.edu.ua>:
>
>> 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.

Not able to. There is some call to amba_get_enable_vcore in probe. It
calls regulator_enable. Which calls some
rdev->desc->ops->enable(rdev). I managed to track enable is part of
struct regulator_ops but I'm not brave enough to track where does it
come from, etc. There are many documented regulator ops, but not
general description. I would have to spend some time on it but I'm not
sure if it's worth that. Not to mention there is some additional
amba_get_enable_pclk which calls some more functions I didn't date to
check.


>> 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.

I guess you mean:
pid |= (readl(tmp + size - 0x20 + 4 * i) & 255) << (i * 8);
cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) << (i * 8);
Well, OK, it proves Broadcom uses AMBA somehow, but not more than that
(at least for me).


>> 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.

Will comment on that later.

-- 
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/