[lkml]   [2008]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PCI-ISA Bridge not operating
    Jordan Crouse wrote:
    > On 11/07/08 14:58 -0400, David Brigada wrote:
    >> David Brigada wrote:
    >>> Jordan Crouse wrote:
    >>>> On 11/07/08 10:58 -0400, David Brigada wrote:
    >>>>> Hi,
    >>>>> I'm working with the MSM800XEV board from Digital-Logic. This board
    >>>>> uses a Geode LX800 for a CPU and has the CS5536 companion board also
    >>>>> installed. The board works with an IT8888G IC that provides a PCI/ISA
    >>>>> bridge to a PC/104 bus that is externally provided.
    >>>>> If I boot with FreeDOS, I can twiddle I/O ports, and the proper ISA
    >>>>> signaling comes over the PC/104 bus. In Linux, the /IOW or /IOR line
    >>>>> goes low as expected, but the address doesn't come over the bus. The
    >>>>> DOS that I'm running doesn't seem to have any specific drivers for the
    >>>>> chip, I'm guessing that the hardware should "just work" --- the IT8888G
    >>>>> is designed to grab I/O requests in the ISA range off the PCI bus after
    >>>>> a short delay if nothing else grabs them first.
    >>>>> I have a feeling that it has something to do with the CS5536 companion
    >>>>> chip, as it seems as though there is a driver for a PCI/ISA bridge on
    >>>>> that chip, though I can't get much detail from AMD's datasheet on that
    >>>>> functionality. I do know that on the MSM800XEV, any such functionality
    >>>>> is wired to the IT8888G, not the CS5536.
    >>>>> There are two kernel config options related to the PCI IDs of the parts
    >>>>> of the device that handle the ISA bus, CONFIG_SCx200_ACB and
    >>>>> CONFIG_CS5535_GPIO. I've tried disabling both, but it doesn't seem to help.
    >>>>> In lspci, the CS5536 PCI/ISA bridge is shown, but not the IT8888G.
    >>>>> Any ideas?
    >>>> ISA should indeed "just work". The only thing I'm wondering is if
    >>>> the kernel is interfering (it shouldn't). I assume that since it works
    >>>> in FreeDOS that there is no possibility that something on the PCI bus
    >>>> is grabbing the cycles instead.
    >>> That's what I'm thinking --- that the CS5536 PCI/ISA bridge is claiming
    >>> the cycles.
    >>>> How are you trying to access the device in Linux? Through a kernel module
    >>>> or a user application running as root?
    >>> I've tried both. I have a kernel module that I wrote for the hardware.
    >>> When I couldn't get that working, I tried looping some code that keeps
    >>> touching the same I/O port that I'm using.
    >>>> Jordan
    >>> Dave
    >> Looking through the documentation for the CS5536, in the "CS56536
    >> Companion Device Data Book," section 5.2.8, it says the following:
    >> > If the SDOFF (Subtractive Decode Off) bit in the GLPCI_MSR_CTRL (MSR
    >> > 51000010h[10]) is cleared (reset value), any PCI transaction, other
    >> > than Configuration Read/Write, Interrupt Acknowledge, and Special
    >> > Cycle transactions, not claimed by any device (i.3., not asserting
    >> > DEVSEL#) within the default active decode cycles (three cycles
    >> > immediately after FRAME# being asserted) will be accepted by GLPCI_SB
    >> > at the fourth clock edge.
    >> This is the same behavior that the IT8888G chip uses --- it waits three
    >> cycles for another device to claim it and then passes the transaction
    >> along. I'm guessing that the CS5536 might be grabbing it (maybe it's
    >> electrically closer, or the logic is more optimized) before the IT8888G
    >> can handle it.
    >> Does this seem feasible as to what could be happening?
    > Sure, but then why does FreeDOS work? It shouldn't be any different
    > when the bits hit the line.
    > Jordan

    That *is* puzzling. When I do lspci, the entry for the IT8888G does not
    appear. I don't have much experience with PCI internals. Would that be
    because there is no driver for it in the kernel, or is there something
    more insidious afoot?


     \ /
      Last update: 2008-07-11 22:17    [W:0.026 / U:71.604 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site