> >>>>>>>> what is the bug number against the firmware? When will the firmware > >>>>>>>> be > >>>>>>>> fixed? > >>>>>>>> > >>>>>>> #define BATT_INTR_SRAM_ADDR 0xFFFF7FC3 > >>>>>>> #define BATT_OCV_SRAM_ADDR 0xFFFF3008 > >>>>>>> > >>>>>>> These address are architectural they will not change across Medfield > >> platforms. Can > >>>> I > >>>>>> hard code > >>>>>>> These addresses based on the point that they will not change? > >>>>>>> > >>>>>>> If not, I have to request the FW team to provide an IPC call to get > >>>>>>> these > >> addresses. > >>>>>> why an IPC call and not a PCI bar ? > >>>>> Battery driver is a platform device... > >>>> and it has a unique sram all to itself???? > >>>> or is it a global shared sram and it just has a few bytes in it > >>>> (I'm fine with #defining an offset within a global sram in a driver.. > >>>> just not fine with #defining the address of the sram like this) > >>>> > >>> It is global shared sram. > >>> audio driver is also uses sram(MIMO interrupt region). But it is PCI > >>> device. > >>> Is it ok to use IPC call to get these addresses? > >> why use IPC if you can just ask the PCI device what it's bar is ???? > > Audio doesn't hard code :) > > We use PCI BAR to get SRAM addresses and other HW regions. > > > > If you are a PCI device please get it thru a PCI BAR > > and if you're not you can ask the PCI bar from the audio device.
Hi Arjan, Sorry to further more extending this discussion. Both of these addresses are from two different Shared SRAM's. If I can get one address from PCI bar of audio driver, how can I get it. Is there any pci interfaces available for this? Thanks, Ram _______________________________________________ MeeGo-kernel mailing list [email protected] http://lists.meego.com/listinfo/meego-kernel
