CompactFlash: IO Ports Prob: GetNextTuple Err

Ports
2002-10-03
2002-10-04
  • Gaurang Khetan
    Gaurang Khetan
    2002-10-03

    Hi,

    I am using a modified form of 2.4.17-rmk5-iop310.1 kernel on a board similar to IQ80310 running a 80200   Intel StrongARM Processor.

    I am trying to access a 512MB Sandisk CompactFlash Card thru a PCI-CardBus bridge, using the kernel PCMCIA support.

    The bridge works fine(uses yenta driver), and the Cardmgr detects the card correctly, but then it gives an error  -

    ide-cs: GetNextTuple: No more items

    due to which I cannot access the device.

    Now this error comes when the ide_cs driver tries to allocate some IO port in ide_config() by calling CardServices with RequestIO, and gets a return error value of CS_IN_USE.

    How should I remove this?

    I have added the following IO windows in /etc/pcmcia/config.opts,
    apart from the memory windows:

    include port 0x90010000-0x9001000f
    include port 0x90010100-0x900101ff
    include port 0x90010800-0x90010fff
    include port 0x90011000-0x90011fff
    include port 0x90012000-0x90012fff
    include port 0x90013000-0x90014fff
    include port 0x90015000-0x90016fff
    include port 0x9001f000-0x9001ffff

    Note that I modified code in the kernel and Cardmgr at numerous places to allow for 32-bit IO port addresses.

    If I remove the memory windows from config.opts, the Cardmanager cannot even read the CIS and cannot identify the card, since it is not able to allocate memory while reading the CIS. So those memory
    windows are necessary.

    If I remove the IO port windows above, then actually I get the same error GetNextTuple: No more items. I guess that the IO windows are also necessary, since the ide_config() function requires that some IO ports be allocated as per the CIS of the card.

    I am pasting the dump_cis output and then then the output with my debugging statements.

    -----
    $ dumpcis

    Socket 1:

    dev_info   
      fn_specific 700ns, 2kb
      common_jedec 0xdf 0x01
      manfid 0x0045, 0x0401
      vers_1 4.1, "SunDisk", "SDP", "5/3 0.6"
      funcid fixed_disk [post]
      disk_interface [ide]
      disk_features [silicon] [unique] [single] [sleep] [standby] [idle] [low power]
      config base 0x0200 mask 0x000f last_index 0x07
      cftable_entry 0x00 [default]
        [rdybsy] [mwait] [pwrdown]
        Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
        memory 0x0000-0x07ff @ 0x0000
      cftable_entry 0x00
        Vcc Vnom 3300mV Ipeak 45mA
      cftable_entry 0x01 [default]
        [rdybsy] [pwrdown]
        Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
        io 0x0000-0x000f [lines=4] [8bit] [16bit]
        irq mask 0xffff [level] [pulse] [shared]
      cftable_entry 0x01
        Vcc Vnom 3300mV Ipeak 45mA
      cftable_entry 0x02 [default]
        [rdybsy] [pwrdown]
        Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
        io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [8bit] [16bit] [range]
        irq 14 [level] [pulse] [shared]
      cftable_entry 0x02
        Vcc Vnom 3300mV Ipeak 45mA
      cftable_entry 0x03 [default]
        [rdybsy] [pwrdown]
        Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
        io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [8bit] [16bit] [range]
        irq 14 [level] [pulse] [shared]
      cftable_entry 0x03
        Vcc Vnom 3300mV Ipeak 45mA
      cftable_entry 0x07

    -----
    Output:

    (this is inside ide_config() in ide_cs driver of the kernel)
    (and "returned 30" means returned CS_IN_USE)
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=0, dflt.io.nwin=0.
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=0, dflt.io.nwin=0.
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=1, dflt.io.nwin=0.
    GK: indx=1, baseport1=0, numports1=16, baseport2=886, numports2=0, IOaddrlines=4
    GK: Starting pcmcia_request_io.
    GK: Entered alloc_io_space: base=0, num=16, lines=4
    GK: Failed. Returned 30
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=0, dflt.io.nwin=1.
    GK: indx=1, baseport1=0, numports1=16, baseport2=886, numports2=0, IOaddrlines=4
    GK: Starting pcmcia_request_io.
    GK: Entered alloc_io_space: base=0, num=16, lines=4
    GK: Failed. Returned 30
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=2, dflt.io.nwin=1.
    GK: indx=2, baseport1=496, numports1=8, baseport2=1014, numports2=1, IOaddrlines=10
    GK: Starting pcmcia_request_io.
    GK: Entered alloc_io_space: base=496, num=8, lines=10
    GK: Failed. Returned 30
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=0, dflt.io.nwin=2.
    GK: indx=2, baseport1=496, numports1=8, baseport2=1014,
    numports2=1, IOaddrlines=10
    GK: Starting pcmcia_request_io.
    GK: Entered alloc_io_space: base=496, num=8, lines=10
    GK: Failed. Returned 30
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=2, dflt.io.nwin=2.
    GK: indx=3, baseport1=368, numports1=8, baseport2=886,
    numports2=1, IOaddrlines=10
    GK: Starting pcmcia_request_io.
    GK: Entered alloc_io_space: base=368, num=8, lines=10
    GK: Failed. Returned 30
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=0, dflt.io.nwin=2.
    GK: indx=3, baseport1=368, numports1=8, baseport2=886,
    numports2=1, IOaddrlines=10
    GK: Starting pcmcia_request_io.
    GK: Entered alloc_io_space: base=368, num=8, lines=10
    GK: Failed. Returned 30
    GK: Entering the while loop.
    GK: 1. cfg->io.nwin=0, dflt.io.nwin=2.
    GK: indx=7, baseport1=368, numports1=8, baseport2=886,
    numports2=1, IOaddrlines=10
    GK: Starting pcmcia_request_io.
    GK: Entered alloc_io_space: base=368, num=8, lines=10
    GK: Failed. Returned 30
    ide-cs: GetNextTuple: No more items

    Thanks

    -Gaurang.

     
    • David Hinds
      David Hinds
      2002-10-04

      I'm not sure that I can answer your question, since I am not familiar with this platform.  I'm somewhat surprised that you needed to make lots of changes to support 32-bit IO addresses since they are already implemented for some platforms (including ARM!).  Be careful about the difference between PCMCIA IO addresses (which are strictly 16-bit by definition) and host bus IO addresses.

      I think most (or all??) PCI-CardBus bridges only permit mapping 16-bit PCMCIA IO addresses into the PCI IO address range 0..ffff.

      -- Dave

       
    • Gaurang Khetan
      Gaurang Khetan
      2002-10-04

      Ok I solved that problem, but another problem has crept up.

      First how I solved that problem:
      I added some different IO port windows in config.opts, which were within the range of the IO ports reserved for the PCI-PCI Bridge, the parent of the PCI-CardBus bridge. This solved the problem. Actually I had done the same with memory windows earlier to solve a  problem with them.

      Now the new problem is:
      This error message appears -
      ide_cs: ide_register() at 0x9001d000 & 0x9001d00e,  irq 14 failed.

      I guess that the problem must be with the irq.

      The PCI-to-PCI bridge is using the same irq (14), is that the source of the problem?

      Another thing could be that this being a custom-designed system, there may have been problems with setting of the IRQ routing tables.

      The ethernet controller is working fine, which also uses IRQ 13.

      I searched on the net, and found a patch by Gunther Mayer on the lkml, which lets the IDE system know that it is allowed to share IRQs, by adding some chipset variable to a hw_regs struct. (which you of course know about)

      However, even after applying his patch, the same error persists.

      Any idea?

      [ I am bothering you a lot.  :-(  ]

      Here are contents of some relevant files.

      --------------
      $ cat /proc/pci

      PCI devices found:
        Bus  0, device   0, function  0:
          Class 0200: PCI device 10ec:8129 (rev 16).
            IRQ 13.
            Master Capable.  Latency=128.  Min Gnt=32.Max Lat=32.
            I/O at 0x9001ff00 [0x9001ffff].
            Non-prefetchable 32 bit memory at 0x8bffff00 [0x8bffffff].
        Bus  0, device   2, function  0:
          Class 0604: PCI device 8086:b154 (rev 0).
            IRQ 14.
        Bus  1, device  11, function  0:
          Class 0607: PCI device 1180:0476 (rev 128).
            IRQ 17.
            Master Capable.  Latency=168.  Min Gnt=128.Max Lat=5.
            Non-prefetchable 32 bit memory at 0x8beff000 [0x8befffff].
        Bus  1, device  11, function  1:
          Class 0607: PCI device 1180:0476 (rev 128).
            IRQ 14.
            Master Capable.  Latency=168.  Min Gnt=128.Max Lat=5.
            Non-prefetchable 32 bit memory at 0x8befe000 [0x8befefff].

      $ cat /proc/interrupts
        1:     212346   timer
        2:       3822   CPLD_IRQ
      11:        238   serial
      13:       3583   eth0
      14:          1   PCI device 1180:0476
      17:          0   PCI device 1180:0476
      Err:          0

      $ cat /proc/iomem
      88000000-8bffffff : IOP310 SATU PCI Mem
        8ae00000-8b5fffff : PCI Bus #01
          8ae00000-8affffff : PCI CardBus #02
          8b000000-8b1fffff : PCI CardBus #06
        8b600000-8befffff : PCI Bus #01
          8b600000-8b7fffff : PCI CardBus #02
          8b800000-8b9fffff : PCI CardBus #06
          8ba00000-8ba00fff : card services
          8befe000-8befefff : PCI device 1180:0476
          8beff000-8befffff : PCI device 1180:0476
        8bffff00-8bffffff : PCI device 10ec:8129
          8bffff00-8bffffff : 8139too
      a0000000-a7ffffff : System RAM
        a0019000-a013ed73 : Kernel code
        a013ed74-a0173c53 : Kernel data

      $ cat /proc/ioports
      90010000-9001ffff : IOP310 SATU PCI I/O
        9001c000-9001efff : PCI Bus #01
          9001c000-9001c0ff : PCI CardBus #02
          9001c400-9001c4ff : PCI CardBus #02
          9001c800-9001c8ff : PCI CardBus #06
          9001cc00-9001ccff : PCI CardBus #06
        9001ff00-9001ffff : PCI device 10ec:8129
          9001ff00-9001ffff : 8139too
      ----------------

       
      • David Hinds
        David Hinds
        2002-10-04

        If it is a resource problem, there should be some other error messages from the IDE driver before you get the "failed" message.  In fact I think there should always be some other messages from the IDE driver in there??

        I'm still concerned that I don't think that the PCI-to-CardBus bridge can map an IO address like 0x9001d000 for your card??  The ExCA registers for describing IO windows only accept a 16-bit IO address.  I think the upper 16 bits are implicitly zero??

        -- Dave