Is CONFIG_VIRTUAL_BUS appropriate?

2003-06-02
2013-04-08
  • I have hardware which implements a very simple compact flash slot.  i.e. No PCMCIA controller, just a simple FPGA which provides limited access to some of the control signals (CD, RDY/BSY and a few others).  The slot sits on an expansion bus which can be configured for either 8 or 16 bit access.  My preference is to operate the bus in 16 bit mode.    Access to the CF registers is via memory mapped addressing to common memory.

    The problem is that in 16 bit mode I do not have access to all of the CF registers, most of which are 8 bits wide.   Through the wonders of of "soft" hardware, I can reconfigure my FPGA to give me multiple "views" of common memory and thus access to 8 bit registers on odd byte boundaries.

    Unfortunately with this method, I cannot setup a memory map that will allow the higher level socket services/card services code direct access to all the registers.  I need to intercept reads/writes so that I can setup the FPGA properly.

    In my serach to find the appropriate method of implementing a driver for my simple CF interface, I came across CONFIG_VIRTUAL_BUS, which provides for the capability of implementing function vectors for bus read/writes among other things.  However there seem to be no users of this capability in the 2.4.19 kernel I am using.  I have looked at other (older?) versions of the kernel where several of the ARM implementations use this feature.

    Question:  Is the use of CONFIG_VIRTUAL_BUS being phased out? Is it appropriate to implement the capabilities I need using CONFIG_VIRTUAL_BUS and the bus_operations defined in include/pcmcia/bus_ops.h:bus_operations structure?  Or perhaps there is some other mechanism, I've only had a short period of time to digest the PCMCIA and CF specs. 

    Thanks in advance for your help, Roger

     
    • David Hinds
      David Hinds
      2003-06-03

      I wrote the virtual bus support for this sort of situation, however, it received little attention and was never really used.  It was taken out of recent 2.5.* kernels, so yes I guess it is being phased out.  If a case can be made that it would be used, maybe it could be reintroduced.

      However, if this CF slot is not really a general purpose PCMCIA controller, maybe an easier thing is just to write an IDE driver stub that knows how to talk to this slot; the core IDE driver allows you to give it a table of functions for reading and writing individual IDE registers, so you could fill those in with whatever is appropriate for your FPGA.  This way you would not need to use the PCMCIA subsystem at all.

      -- Dave

       
    • Dave,  Thanks.  I'll take a look at that approach.  -Roger

       
    • Harry Lin
      Harry Lin
      2003-10-31

      Hi, Roger and Dave -

      I am facing the very similar situation --
      I have had a simple fpga to glue the system bus to a CF+ interface, and verified i can access attr/cfg mem as well as io/mem space in either 16/8 bit operations. I plan to plug in a wifi CF card to have a simple 802.11b support.

      reasonally as the very next step I came to the linux pcmcia-cs codes, in the hope that i can find an easy route to hook up my "socket service" (no pcmcia or alikes controller at all, but a simple glue logic to generate cf+ cycles, to detect existence of the card, etc) to the rest of pcmcia-cs stuff. thus using the existing wlan client drivers built on top of the pcmcia-cs.

      well it appears to me that its hard to make a clean map for my "socket driver" to mimic a real pcmcia controller (like tcic, or intel 82365) to the upper layer of pcmcia-cs.....

      CONFIG_VIRTUAL_BUS seems to be a way, I'd really appreciate if you can share some thoughts on how you make out of virtualizing the bus_operations structure, if you ever tried it. or any ideas on how to work around for a simple straightforward solution

      Thanx

      Harry

       
      • David Hinds
        David Hinds
        2003-11-01

        CONFIG_VIRTUAL_BUS was designed for cases where a controller does not map host addresses to PCMCIA bus addresses.  If that's the case for your glue chip, then yes, that's what this is for.

        Only the core PCMCIA services were ever modified to use the bus_operations stuff; client drivers never got implemented.  The reason was that I did it to help someone with a socket driver he wanted to write, but he never wrote it, and I never had any use for the stuff.

        So... it is there, and there is some documentation in the Programmer's Guide, but that's about all I can do for you.  Using it would lock you in to using the pcmcia-cs drivers, since it has been dropped from the kernel PCMCIA implementation.

        Since the infrastructure is incomplete, it might be just as easy to take the PCMCIA client driver you're interested in using, and hack that up to talk to your glue chip and configure the card directly rather than using the PCMCIA services.

        -- Dave

         
    • ytkim
      ytkim
      2004-10-18

      Hi, Dave.

      I have made a 801.11b AP with CONFIG_VIRTUAL_BUS on the ARM system bus and HOSTAP driver.

      Thank you very much.

       
    • J.Bright
      J.Bright
      2004-10-19

      Our hardware does not have a PCI or ISA bus and also does not have a tcic or i82356 (or compatible) host controller. PCMCIA registers are mapped into the memory at a pre-defined address. Anything with the PCMCIA interface could only be done by writing to and reading from the PCMCIA registers in the memory.

      Building the pcmcia-cs modules with CONFIG_PCI or CONFIG_ISA not set results in error "No bus architectures defined". Would CONFIG_VIRTUAL_BUS help in this situation. Any guideline in this regard will be greatly appreciated.

       
      • ytkim
        ytkim
        2004-10-21

        Hi, J.Bright.

        First, I have patched all pcmcia-cs to linux kernel and compiled as static, not module.
        I have wrote a socket driver from the i82365.c and modified cistpl.c and hostap_cs.c because of our address bus lines connected to pcmcia socket.
        This socket socket driver is not a general socket driver but a special driver for my 16bit PC-Card.

        i82365.c has two parts - PCI, ISA.
        I have modified almost ISA part and added these functions for CONFIG_VIRTUAL_BUS,

        static struct bus_operations iobus_operations = {
                NULL,
                iobus_in,
                iobus_ins,
                iobus_out,
                iobus_outs,
                iobus_ioremap,
                iobus_iounmap,
                iobus_read,
                iobus_write,
                iobus_copy_from,
                iobus_copy_to,
                iobus_request_irq,
                iobus_free_irq
        };

        and more info for you is

            t[i].cap.features |= SS_CAP_PCCARD;    //16-bit PC cards
            t[i].cap.features |= SS_CAP_VIRTUAL_BUS;//card access must be performed
                                //using the bus operations
                                //table, rather than using
                                //native bus operations.
            t[i].cap.features |= SS_CAP_STATIC_MAP;    //fixed positioned window
            t[i].cap.features |= SS_CAP_PAGE_REGS;     //allow 32bit addressing
            t[i].cap.features |= SS_CAP_MEM_ALIGN;    //fixed sized window
            t[i].cap.irq_mask = 0xffff;
            t[i].cap.map_size = 0xf00000;    //16MB
            t[i].cap.io_offset = pcmcia_base;    //IO Memory Base
            t[i].cap.pci_irq = 0;
            t[i].cap.cb_dev = NULL;
            t[i].cap.bus = &iobus_operations;

            t[i].cs_irq = isa_irq;.

        'pcmcia_base' is the ioremaped address pointing to I/O memory not attribute memory.
        't[i].cap.io_offset' is no more valid in recent pcmcia-cs and I have no idea.
        t[i] is socket_info_t defined in i82365.c.

        Good luck !!!