2011/4/13 George Kashperko <george@xxxxxxxxxxx>: > >> 2011/4/13 Arend van Spriel <arend@xxxxxxxxxxxx>: >> > On Tue, 12 Apr 2011 22:44:01 +0200, RafaÅ MiÅecki <zajec5@xxxxxxxxx> wrote: >> > >> >> 2011/4/12 George Kashperko <george@xxxxxxxxxxx>: >> >>>> >> >>>> 2011/4/12 RafaÅ MiÅecki <zajec5@xxxxxxxxx>: >> >>>> 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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
