> -----Original Message----- > From: [email protected] [mailto:meego-kernel- > [email protected]] On Behalf Of Arjan van de Ven > Sent: Thursday, December 16, 2010 8:02 PM > To: Pallala, Ramakrishna > Cc: meego-kernel > Subject: Re: [Meego-kernel] [PATCH] mrst.c changes for Intel MSIC battery > driver... > > On 12/16/2010 4:34 AM, Pallala, Ramakrishna wrote: > >> On 12/15/2010 2:51 AM, Pallala, Ramakrishna wrote: > >>>>>> 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 are platform device get the base address as a platform resource. Other way would be to add it in your driver data (as this thing will be constant for a platform) ~Vinod _______________________________________________ MeeGo-kernel mailing list [email protected] http://lists.meego.com/listinfo/meego-kernel
