2011/4/13 RafaÅ MiÅecki <zajec5@xxxxxxxxx>: > Will comment on that later. Can we try to decide, how to implement our driver correctly? This should be main focus for now. I tried to analyze drivers/amba/, how it works, how it relates to our code, Broadcom. AFAICS AMBA so far is mostly (always?) used for embedded devices with pre-defined hardware layout. Let's take as example mach-u300 (just some random one). One of the amba_devices it registers is uart0_device which has two interesting fields: .start = U300_UART0_BASE, .end = U300_UART0_BASE + SZ_4K - 1, U300_UART0_BASE == (U300_SLOW_PER_PHYS_BASE+0x3000) == 0xc0013000 So this mach-u300 is well-specified device, every mach-u300 has uart0 at 0xc0013000. It looks every AMBA device (like uart0) has some common fields, like: u32 peripherialid0, peripherialid1, peripherialid2, peripherialid3; u32 componentid0, componentid1, componentid2, componentid3; I believe Broadcom's *agent* AKA *wrapper* is comparable to standard amba device. Of course agents/wrappers are not the same for every Broadcom AMBA AXI card, so we can not use strict .start and .end declarations and the same agents/wrappers for every card. Instead, we have to do scanning of EPROM to read info about agents/wrappers. If someone does not know: every core on Broadcom AMBA AXI card has it's agent/wrapper. We access agent/wrapper registers to enable/disable/reset core. So we could scan EPROM for agents/wrappers, register them in AMBA driver using our *_core_enable as AMBA's clock management. Please verify if my understanding is correct. I tried to explain easily whole situation I just analyzed. If I'm right: is this really the right path to follow? What about real core, like PCIe core, or IEEE core? I guess they are not standard AMBA cores, so we can not simply register them. Should we look for clever way to connect everything we have with drivers/amba? How to connect "real" cores (PCIe, IEEE) with agents? Please, share how do you see this situation now. -- RafaÅ _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
