I2C module problem on 8260

I2C module problem on 8260

[Eric.Oosterhof]

I'm having a problem with the I2C on a custom 8260 board.  I modified the
8xx device driver (I've seen it called the Dan Malek driver) and am trying
to load it as a module.  I discovered in so doing that the virtual address
space that the module is placed in does not allow the use of __pa to get a
virtual address.  I looked at the 860 driver that we are using on a
different board, and it has the same issue.  But, it is compiled into the
kernel, hence won't have that problem.  My question is two-fold.  First, is
there a smarter version of __pa that understand how to get the physical
address of a construct in a dynamically loaded module?  Second, is this a
bug in the I2C, and I just happened to be using the module form where the
bug shows up?  I have included below the output (snipped) of insmod -m to
show the symbol.  My system has only 64 MB of SDRAM, hence virtual SDRAM
addresses range from 0xc0000000 to 0xc3ffffff.  Thanks!

sh-2.04# insmod -m i2c-algo-8260.o
Sections:       Size      Address   Align
.this           00000060  c5008000  2**2
.text           00000ad8  c5008060  2**2
.rodata         000004bc  c5008b38  2**2
.kstrtab        0000010a  c5008ff4  2**2
__ksymtab       00000038  c5009100  2**2
.data           0000003c  c5009138  2**2
.sdata          00000008  c5009174  2**2
.vtop_fixup     0000001c  c500917c  2**1
.bss            00000010  c5009198  2**2
.sbss           00000004  c50091a8  2**1
.plt            00000080  c50091b0  2**4
.kmodtab        0000000c  c5009230  2**2
__archdata      00000000  c5009240  2**4

Symbols:
00000000 a i2c-algo-8260.c
...
...


Eric.Oosterhof@RadiSys.com    503-615-1283
5445 NE Dawson Creek Drive
Hillsboro, Oregon, 97124
USA


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I2C module problem on 8260

[Dan Malek]

Eric.Oosterhof@radisys.com wrote:

> .....  I discovered in so doing that the virtual address
> space that the module is placed in does not allow the use of __pa to get a
> virtual address.

Welcome to the wonderful world of Linux VM and the need for different
implementations depending upon how you use the driver.  The 8xx and 4xx
processors use the 'iopa()' function within the usual macros to do this.
Outside of those processors, you can call it directly.  Change the __pa()
to iopa() and you should be fine.

There are other things you must consider.  Loadable modules dynamically
allocate pages of memory, so they are likely not to be physically contiguous.
One of the programming techniques for modules is you must explicitly allocate
all objects subject to DMA such that they are known to be physically contiguous
if necessary.  The static buffers you allocate in a built-in driver won't work
for DMA in a module.

Finally, there isn't any deallocation function for CPM memory space.  I thought
someone else was going to contribute this, and I apologize if I misplaced a patch,
but this needs to be done or else your module loading/unloading will exhaust
the CPM dual port memory space.  I guess I can quickly do one that used the old
unix style map allocator, but I never got around to do it.  Due to the interactions
of the devices on the CPM for resource allocation and the configuration
interdependencies, I always found it easier to just build a static driver and
reboot the kernel.

Have fun!


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I2C module problem on 8260

[Wolfgang Denk]

In message <3C69A0EC.2090400@embeddededge.com> you wrote:
>
> Finally, there isn't any deallocation function for CPM memory space.  I thought
> someone else was going to contribute this, and I apologize if I misplaced a patch,

I've sent such patches to Tom Rini many months ago (starting  29  Aug
2001),  and  in some iterations again and again. It's for 8xx only so
far, but adaption for 82xx is just a small exercise.

Unfortunately, this patch was always ignored (as some  others,  too),
so I finally gave up.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
See us @ Embedded Systems Nuremberg, Feb 19-21, Hall 12 K01 (with TQ)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I2C module problem on 8260

[Murray Jensen]

On Wed, 13 Feb 2002 00:18:08 +0100, Wolfgang Denk <wd@denx.de> writes:
>I've sent such patches to Tom Rini many months ago (starting  29  Aug
>2001),  and  in some iterations again and again. It's for 8xx only so
>far, but adaption for 82xx is just a small exercise.

Well, I have an i2c driver for the CPM which supports both 8xx and 8260
(and potentially anything else that has a CPM) in the same source (although
I still haven't got around to testing the 8xx code). I avoid the issue raised
here by using kmalloc(). The code works fine as a loadable module, and it
only allocates the dual port ram once, the first time the module is loaded.
Of course, it is called drivers/i2c/i2c{-algo,}cpm.c.

These patches (amongst a whole lot of others) were also submitted around that
same time. After much back and forth I was asked to post the patches to this
list, which I have been meaning to do for many months now.

Initially, I was asked to submit the i2c changes via the i2c driver people,
but I countered this by pointing out that they really couldn't care less
about driver code for embedded powerpc (CPM), since it will never run on
anything else (as opposed to a driver for a PCI card which may work on
multiple platforms). We really only submit our code back to them for the
sake of completeness.

>Unfortunately, this patch was always ignored (as some  others,  too),
>so I finally gave up.

Hmm.. I wonder if we are being too careful about allowing stuff into the
_devel tree - isn't that what its for? Development stuff that might break
things? Besides, there are already some changes that make it in that severely
break things for some platforms - we all just put up with it and fix the
problems as they arise (witness the recent change in operation of the get_irq
function - the 8260 platform hung during boot the first time interrupts were
enabled, and it stayed that way for many months until I finally decided to
track the problem down).

Now, I'm not criticising anyone's effort, decisions or contributions here,
simply discussing our operational policy in a calm manner in the hope that
things might be freed up a bit (of course I recognise the chaos that could
arise if all changes were simply immediately incorporated without question,
but there has to be a happy medium somewhere).

Anyway, I should get off my arse and post those patches - I think there
is some good stuff in them (but then I would, wouldn't I). Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I2C module problem on 8260

[Dan Malek]

Dan Malek wrote:



> One of the programming techniques for modules is you must explicitly
> allocate
> all objects subject to DMA such that they are known to be physically
> contiguous
> if necessary.

I should have also mentioned that using these functions also returns
both physical and virtual addresses that you should keep within your
driver so you can avoid calling any function/macro that converts
between physical and virtual addresses.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I2C module problem on 8260

[Eric.Oosterhof]

On Wed, 13 Feb 2002 17:43:57 +1100, Murray Jensen <
Murray.Jensen@cmst.csiro.au> writes:
>Well, I have an i2c driver for the CPM which supports both 8xx and 8260
>(and potentially anything else that has a CPM) in the same source
(although
>I still haven't got around to testing the 8xx code). I avoid the issue
raised
>here by using kmalloc(). The code works fine as a loadable module, and it
>only allocates the dual port ram once, the first time the module is
loaded.
>Of course, it is called drivers/i2c/i2c{-algo,}cpm.c.

Yes, thanks for the responses.  That was my solution too, and it is now
working.  Next up, how to get it to respond as a slave.  My hardware has 4
8260's, and they communicate via I2C.  I want one CPU to be the I2C master
and the other 3 to be slaves.  Potentially, I could make them all masters,
but that might require SW mods to support the multi-master environment.  Is
anyone aware of either solution?

Eric.Oosterhof@RadiSys.com 503-615-1283
5445 NE Dawson Creek Drive
Hillsboro, Oregon, 97124
USA


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/