Re: PPC RTC on I2C

In message [off-list ref] you wrote:

[Tim]

quoted

I'm working on getting i2c support working on a module that has its
RTC on i2c.

Nothing new. Has been done before.

quoted

I've got my i2c client written, but i2c-core and friends don't load
until very late in the game; setting ppc_md.get/set (at least in
platform_init) is not very useful.

So delay the initialization until I2C is available.

quoted

Any thoughts on a graceful way to implement kernel RTC support using
an i2c-based RTC (w/o bypassing the kernel's i2c layer)?

See for example the CU824, CPU86,  or  PM826  configurations  in  our
kernel tree which all use a PCF8563 RTC.

[Matt]

I always thought that one would implement some low-level ppc-specific
i2c master access functions.  These would be available via a few
ppc_mds and one could have a generic i2c 'adapter' to call the
functions.  For RTC access, one would then have a i2c RTC implementation
using these access functions rather than using the generic PPC RTC
device.  This does bypass the bloated i2c layer, however.  If done

IMHO the whole I2C system is  (1)  overkill  and  (2)  unusable.  For
example, we often have to deal with PICs and other devices on the I2C
bus  where  you  must  first  issue a write operation (for example to
select a register) followed  by  one  or  more  read  operations  (to
receive  the  data).  This is difficult to implement application code
that perform such accesses when there is more than  one  device,  and
more  than one application process. Things get worse if you also have
to provide simultaneous access tot he  I2C  bus  from  one  ore  more
device drivers.

But this is a different story...

One could modify the i2c layer to hook up early access of i2c master
devices.  This would be similar to the early initialization of 550

You can also just delay the initialization of the RTC until  the  I2C
RTC driver loads...


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
We are Microsoft. Unix is irrelevant. Openness is futile.  Prepare to
be assimilated.

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

[Matt]

quoted

I always thought that one would implement some low-level ppc-specific
i2c master access functions.  These would be available via a few
ppc_mds and one could have a generic i2c 'adapter' to call the
functions.  For RTC access, one would then have a i2c RTC implementation
using these access functions rather than using the generic PPC RTC
device.  This does bypass the bloated i2c layer, however.  If done

[Wolfgang]

IMHO the whole I2C system is  (1)  overkill  and  (2)  unusable.  For
example, we often have to deal with PICs and other devices on the I2C
bus  where  you  must  first  issue a write operation (for example to
select a register) followed  by  one  or  more  read  operations  (to
receive  the  data).  This is difficult to implement application code
that perform such accesses when there is more than  one  device,  and
more  than one application process. Things get worse if you also have
to provide simultaneous access tot he  I2C  bus  from  one  ore  more
device drivers.

It's not unusable. For the kind of access you are describing there is
a ioctl() i/f where you kan combine all you read/write operations into
one atomic system call. It's available inside the kernel as a function
call, i2c_transfer(), as well.

Tim, if you are using a 8xx CPU, make sure to get a updated version of
the i2c-algo-8xx.c driver from BK curr, 2.4 devel branch.

  Jocke


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