First -- here is the data from Inhand on their mappings from the pcmcia
controller:
#define PCCardBase (0x30000000)
#define PCCard0Base (PCCardBase)
#define PCCard0IOBase (PCCard0Base + 0x00000000)
#define PCCard0AttrBase (PCCard0Base + 0x08000000)
#define PCCard0MemBase (PCCard0Base + 0x0C000000)
#define PCCard1Base (PCCardBase)
#define PCCard1IOBase (PCCard1Base + 0x00000000+SocketIOWindowLen)
#define PCCard1AttrBase (PCCard1Base + 0x08000000 +SocketMemoryWindowLen)
#define PCCard1MemBase (PCCard1Base +0x0C000000 + SocketMemoryWindowLen)
#define PCCardIndexRegister (PCCard0IOBase + 0x000003E0)
#define PCCardDataRegister (PCCardIndexRegister + 1)
I have changed the i82365.c set_mem_map to deal with the offsets in memory
addresses, and all is well as cardmgr and cardctl see the cards and can
read the data from them.
OK -- here is the chain of events that I have changed for IO, starting
with init_i81265 which is the module/drivers entry point:
* __ioremap IndexRegister for size 0x02, 0 for flags
* __ioremap 0x30000000 size 0x7fff, 0 for flags -- socket 0 IO
* __ioremap 0x30008000 size 0x7fff, 0 for flags -- socket 1 IO
* add_socket for each socket, same index and data register for each as the
controller only has one ??
* add_pcic for 2 sockets
-- add_pcic does the following:
* request_region IndexRegister, size 0x02 -- dont know why, was done
already as part of the driver
* use the ioremaped address for each of the sockets IO from above as the
io_offset in t[i].cap.io_offset.
-- set addresses in io mapping for each socket as:
* map 0 : 0x00 to 0x3df
* map 1 : 0x3e2 to 0x7fff
-- this excludes the index and data register
Now when I try and insert a driver ( orioco_cs ), I get random wierd
errors when it tries to do a hermes_reset() ( a hardware reset ). The
hermes DEBUG messages take the io_offset address used above as the
hw->base address.
The error messages will say things such as taking 5000 iteration to reset,
or that the card was removed during the reset..etc.
I have complete debug traces from the DEBUG statements in hermes.c,
orinoco.c, orinoco_cs.c, cs.c, ds.c, and i82365.c if you would like a
more complete picture of what is happening.
Thanks!!!
Nic
On Sun, 27 Jan 2002, Russell King - ARM Linux wrote:
> On Fri, Jan 25, 2002 at 10:05:59PM -0500, henken wrote:
> > I am still working with the fun and lovely i82365 driver on the Elf. To
> > get the sockets IO ports to be accessible, I have to ioremap the
> > addresses. There is also an additional ioremap for the index register and
> > data register. All 3 ioremaps appear to succeed as they return valid
> > addresses, but when I look in /proc/ioports, I only see the ioremap for
> > the index and data registers.
>
> /proc/ioports isn't updated by ioremap. Its updated by calls to
> request_region() and release_region(). You're getting into a dodgy
> area with resource management on these platforms - its best to ignore
> /proc/ioports and rely on /proc/iomem only.
>
> (/proc/iomem is maintained by a couple of other, similarly named, function
> calls).
>
> > When I try to access the IO port maps for the sockets, the drivers
> > get weird, as if the remapping didnt work. Any ideas?
>
> Can you be more specific?
>
> _______________________________________________
> http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
> Please visit the above address for information on this list.
>
--
Nicholas Henke
Undergraduate - Engineerring 2002
--
Senior Architect and Developer
Liniac Project - University of Pennsylvania
http://clubmask.sourceforge.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's nothing like good food, good beer, and a bad girl.
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
