Re: 2.6.20 PCI Cannot allocate resource region 2

From: Manu Abraham
Date: Tue Feb 06 2007 - 03:48:24 EST


On 2/6/07, Grant Grundler <grundler@xxxxxxxxxxxxxxxx> wrote:
On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote:
...
> >BIST is required to complete in 2 seconds. Either with success or failure.
> >I expect BIOS to have complained before launching grub/lilo.
...
> BIST is supposed to terminate before, say the OS kernel is loaded?

Yes - that's what I was trying to imply above.

> or does it mean that it can keep running still ?

Don't know. Either it's still running (for much longer that 2 seconds),
linux is causing it run _again_, or linux is has terribly confused the
device somehow. More on this in an email I'm still working on...will
send that out in a bit.

i think probably, Linux is causing it to run again .. ?


> >> Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled]
> >[size=4K]
> >> Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled]
> >[size=4K]
> >> Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
> >> Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
> >> Region 5: Memory at <invalid-64bit-slot> (64-bit,
> >non-prefetchable) [disabled]
> >
> >This is obviously garbage. 64-bit registers can only be represented with
> >two consecutive "BAR" and region 5 is the last one.
> >There is no way this can be a 64-bit BAR.
> >Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten
> >again if that's just convention or a requirement)
> >
>
> was just wondering how it could be a 64 bit device.

64-bit BAR is seperate from 64-bit Device (data path).

PCI has three different 32 vs 64-bit areas:
o BARs
o DMA
o HW/data path width.

"32-bit device" generally only refers to the latter.
The three attributes are generally all "32-bit" for "32-bit device".


According to the information i have on this device ..

Configuration Register 00H : Device_ID / Vendor_ID Register
Bit [31:16] R Device_ID Device ID = 16'h4e35
Bit [15:0] R Vendor_ID Vendor ID = 16'h1822

Configuration Register 04H : Status / Command Register
Bit 31 R Detpar_rpt Detect Parity Report
Bit 30 W/R System_err Indicate System Error
Bit 29 R Master_abort Indicate Master Abort
Bit 28 R Target_abort Indicate Target Abort
Bit [27:25] Default = 3'b001
Bit 24 R Datapar_rpt Data Parity Report
Bit [23:20] Default = 4'b0000
Bit [19:16] Default = 4'b0000
Bit [15:9] Default = 7'h0
Bit 8 W/R Pci_serr_en PCI system error enable
Bit 7 Default = 1'b0
Bit 6 W/R Pci_perr_en PCI parity error enable
Bit [5:3] Default = 3'h0
Bit 2 W/R Pci_master_en PCI master mode enable
Bit 1 W/R Pci_target_en PCI target mode enable
Bit 0 Default = 1'b0

Configuration Register 08H : Class_Code / Revision_ID Register
Bit [31:8] R Class_Code Class_Code = 24'h048000
Bit [7:0] R Revision_ID Revision_ID = 8'h01

Configuration Register 0CH : Latency Timer Register
Bit [31:16] Default = 16'h0
Bit [15:11] W/R Pci_lat_timer Indicate PCI latency timer
Bit [10:8] Default = 3'h0
Bit [7:0] Default = 8'b0

Configuration Register 10H : Base_Address / Memory&Prep Register
Bit [31:12] W/R Pci_base_addr Indicate PCI Base Address
Bit [31:0] R Default = 12'h008

Configuration Register 2CH : I2C Subsystem_ID / Subsystem_Vendor_ID Register
Bit [31:0] W/R I2c_ssid_ssvid Indicate I2C subsystem_ID / subsystem_vendor_ID

Configuration Register 38H : Test PCI Connection Register
Bit [31:0] W/R Test_pci_conn Indicate to test PCI connection

Configuration Register 3CH : Max_Latency / Min_Gnt / Int_Pin / Int_Line Register
Bit [31:24] W Max_lat Default = 8'hFF
Bit [23:16] W Min_gnt Default = 8'h08
Bit [15:8] W Int_pin Default = 8'h01
Bit [7:0] W/R Int_line Indicate interrupt line



That's less likely to be true for "64-bit devices". Several "64-bit
devices" can only DMA to 32-bit host memory and at least a few only
support 32-bit BARs (even if the device claims it has a 64-bit BAR).



AFAIK, the device does 32 bit DMA, but it is not completely hardware driven DMA.
it just uses a RISC core which just jumps to the pointer allocated in software.

The other devices using the same chip, works that way.

hth,
grant


thanks,
manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/