PPC RTC on I2C

PPC RTC on I2C

[Montgomery, Tim]

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)?

Apologies if I've missed something obvious.

Regards,
Tim


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

"Extra cflags for kbuild 2.4." [ _devel tree ]

[Mark Pilon]

Hi,

I've been away from the list for a few months and would appreciate
some larger context w/ that comment and cflags in Makefile --

I'm confused as include/linux/kernel.h includes stdarg.h, but
the 'extra cflags' specify: -nostdinc -iwithprefix include,
causing this inclusion not to be satisfied ...

commenting out:
kbuild_2_4_nostdinc	:= -nostdinc -iwithprefix include
export kbuild_2_4_nostdinc

causes the build to compile better.

my apologies if I've missed something here;

Mark


--
Mark Pilon
Minolta-QMS

P.O. Box 37
325 Dawson County Road 227
Fallon, MT.  59326-0037
1-406-486-5539 (primary voice line)
1-406-853-0433 (cell)

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

Re: PPC RTC on I2C

[Matt Porter]

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/

Re: PPC RTC on I2C

[Dan Malek]

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/

Re: PPC RTC on I2C

[Wolfgang Denk]

In message <20021125161239.A20831@home.com> you wrote:
>

[Tim]
> > I'm working on getting i2c support working on a module that has its
> > RTC on i2c.

Nothing new. Has been done before.

> > 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.

> > 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/

RE: PPC RTC on I2C

[Joakim Tjernlund]

> [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

[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/

Re: PPC RTC on I2C

[leeyang]

Why not use RTC in the PPC core?

----- Original Message -----
From: "Montgomery, Tim" <timm@artesyncp.com>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Tuesday, November 26, 2002 6:13 AM
Subject: PPC RTC on I2C

> 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)?

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

QMC driver for 860?

[Joakim Tjernlund]

Hi all

Does anyone know of a QMC driver for the PPC860?
It does not have to be perfect, I will take anything since
I have not been in this area before.

 Thanks

    Jocke


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

Re: QMC driver for 860?

[Pantelis Antoniou]

Joakim Tjernlund wrote:

>Hi all
>
>Does anyone know of a QMC driver for the PPC860?
>It does not have to be perfect, I will take anything since
>I have not been in this area before.
>
> Thanks
>
>    Jocke
>
>
>
>
>
>
>
I have something that works for the MPC850.
Unfortunately it is kinda complex and too much tied
to my custom hardware to be of any use directly.
I.e. be prepared to hack it a bit. Email me if you are interested...

Pantelis Antoniou
INTRACOM S.A. Greece


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

RE: QMC driver for 860?

[Joakim Tjernlund]

> >Hi all
> >
> >Does anyone know of a QMC driver for the PPC860?
> >It does not have to be perfect, I will take anything since
> >I have not been in this area before.
> >
> > Thanks
> >
> >    Jocke
> I have something that works for the MPC850.
> Unfortunately it is kinda complex and too much tied
> to my custom hardware to be of any use directly.
> I.e. be prepared to hack it a bit. Email me if you are interested...
>
> Pantelis Antoniou
> INTRACOM S.A. Greece

Yes, please sent it. I am interested in any driver I can get my hands on.
Even if it's not directly usable, I can always learn from it.

Anybody else that have a QMC driver, please don't hesitate to send me a copy.

 Thanks
       Jocke


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

Re: "Extra cflags for kbuild 2.4." [ _devel tree ]

[Milton D. Miller II]

You didn't say which compiler you were using.  This code was added to
prevent user space headers from being included.  The -iwithprefix include
was supposed to cause gcc to add its compiler include path to the headers.
I think i read on lkml that one version of the compiler didn't do the
right think and there is an alternative command (probably posted by
Keith Owens) -- make sure you get the one that sets LANG.

milton

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