Somnath kotur wrote:
Garrett,
Thanks, so essentially what you are saying is that rnumber 1 => BAR 1
rnumber 2 => BAR 2
rnumber 3=> BAR 4 Is that correct?

For your device with 64-bit addressing capability, it is.


The problem that i am facing is that when i do call the ddi_regs_map_setup() with the above rnumbers with (void * ) being the datatypes of the paramters holding the base_addr eg:
ddi_dev_regsize(devinfo, 2, (off_t *)&mem_size );

if ((ddi_regs_map_setup(devinfo,2,
             (caddr_t *)&adapter->ctrl.csr,0,mem_size,
             &accattr1, &adapter->ctrl.csr_handle)) != DDI_SUCCESS)

The adapter->ctrl.csr address returned by the above API is not the same value 
as output by the 'prtpci ' utility as show below:

BAR[1]: 32-bit memory 0xfe4f8000 0x4000
BAR[2]: 64-bit memory 0xfe480000 0x20000
BAR[4]: 64-bit memory 0xfe460000 0x20000

Oh, they won't be the same at all. The addresses displayed by prtpci are physical PCI addresses. The addresses returned by ddi_regs_map_setup() are kernel virtual addresses.

The mapping between these two sets of addresses can be simple, or it can be very complex, depending on the physical platform and whether an IOMMU is involved or not.

   - Garrett
Thanks
Som



--- On Thu, 6/4/09, Garrett D'Amore <gdam...@opensolaris.org> wrote:

From: Garrett D'Amore <gdam...@opensolaris.org>
Subject: Re: [driver-discuss] Problem understanding ddi_regs_map_setup()
To: "Somnath kotur" <so...@yahoo.com>
Cc: "Garrett D'Amore" <gdam...@sun.com>, driver-discuss@opensolaris.org
Date: Thursday, June 4, 2009, 6:33 AM
Somnath kotur wrote:
Thanks a lot Garrett , im still not clear about one
thing, if rnumber 0 is indeed PCI Config space , when i
attempt ddi_dev_regsize() with rnumber=0 i get a mem_size of
0 ?? The only rnumbers that seem to work for me when  i
try rnumbers 0- 6 are 1,2&3. Could you pls explain ?
Yes... you can't inquire the size of pci configuration
space because the algorithm that is used to detect memory
sizes can't be done with PCI config space -- its size is
fixed by the PCI standard.  Nobody would ever write
code to test for that size in a real driver.

   -- Garrett
  Thanks
Som

--- On Thu, 6/4/09, Garrett D'Amore <gdam...@sun.com>
wrote:
From: Garrett D'Amore <gdam...@sun.com>
Subject: Re: [driver-discuss] Problem
understanding ddi_regs_map_setup()
To: "Somnath kotur" <so...@yahoo.com>
Cc: driver-discuss@opensolaris.org
Date: Thursday, June 4, 2009, 6:09 AM
Somnath kotur wrote:
Hi All,
          I have been
trying to map the BARs of my PCI-e Card which has
2
functions that my driver wants to support.  I
went to
this site that helps to understand and digest
prtconf
output,copy pasting the link here 
http://blogs.sun.com/dmick/entry/prtpci_digest_and_display_prtconf
I downloaded and used the utility that is
there on the
above website called prtpci and ran it
Snippet of the output i got below:

BAR[1]: 32-bit memory 0xfe4f8000 0x4000
BAR[2]: 64-bit memory 0xfe480000 0x20000
BAR[4]: 64-bit memory 0xfe460000 0x20000


But when i do ddi_regs_map_setup() to try and
map the
above registers in my driver , the 'rnumber'
that i
use don't seem to correspond to the numbers 1,2
&4 ,
instead i seem to get valid reg_sizes only for
'rnumbers'
for 1,2 &3 . I dont understand this , i mean
it's not a
1-1 mapping with the BAR register numbers as shown
above ,so
what exactly is it ? and how to relate these
'rnumbers' to
the BAR numbers now?
I believe that because you have 64-bit BARs, you
are really
just using the rnumbers in numerically ascending
order.
rnumber 0 is PCI configuration space, rnumber 1 is
the first
BAR on the device, rnumber 2 the second BAR, and
so forth.
(For 32-bit PCI devices, you'd probably have a
non-zero
BAR[3] above....)

- Garrett
Thanks
Som



_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
   _______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss




_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss

Reply via email to