On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
quoted text
> 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 .. ?


quoted text
> > >>       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



quoted text
> 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.

quoted text
> hth,
> grant


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