On Mon, Nov 25, 2002 at 04:13:17PM -0600, Montgomery, Tim wrote:
Hey all,
I'm working on getting i2c support working on a module that has its
RTC on i2c.
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.
Any thoughts on a graceful way to implement kernel RTC support using
an i2c-based RTC (w/o bypassing the kernel's i2c layer)?
Hi Tim,
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
properly, though, one could follow a similar strategy to that of
serial.c and with proper locking allow two paths to the hardware
registers.
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
uarts that is available in that driver. When the full driver is
initialized then accesses would occur in the normal manner.
Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Matt Porter wrote:
I always thought that one would implement some low-level ppc-specific
i2c master access functions.
It depends upon the board implementation. If you have devices other
than the RTC on the I2C bus it becomes a big mess. I've had a couple
of boards with I2C RTCs, but it was the only device connected to
a couple of special purpose GPIOs, so I just used a minimal software
toggle function to do the job. You have to keep in mind the RTC is
usually updated during the timer interrupt, not a place you want to
be calling the heavyweight I2C layer, especially if there are other
devices you may get queued behind on the bus. :-)
The timer RTC functions are written assuming you only need a
few, low latency, register accesses to read or update the RTC. This
is also done to ensure hardware clock synchronization. Placing an
access like this on an I2C queue, if it can be made to work, will
certainly break this synchronization.
... These would be available via a few
ppc_mds and one could have a generic i2c 'adapter' to call the
functions.
There are already ppc_mds to read/write the RTC time from the kernel
timer functions. You just need to install something that Does The
Right Thing. :-)
....rather than using the generic PPC RTC
device.
The problem with the "generic" RTC functions is they assume one of
a few possible parts connected in one of a few possible memory mapped
methods. I can't use CONFIG_PPC_RTC on many embedded boards, I just
let the board configuration select the RTC support functions. Yes, it
may be I2C but I don't configure I2C to make it work.
.... When the full driver is
initialized then accesses would occur in the normal manner.
I don't think this would ever work for the kernel RTC access. Check
into it very carefully before you commit to this path.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/