LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: Matt Porter <porter@cox.net>
Cc: "Montgomery, Tim" <timm@artesyncp.com>,
	linuxppc-embedded@lists.linuxppc.org
Subject: Re: PPC RTC on I2C
Date: Tue, 26 Nov 2002 00:07:26 +0100	[thread overview]
Message-ID: <20021125230731.43D9DC58BF@atlas.denx.de> (raw)
In-Reply-To: Your message of "Mon, 25 Nov 2002 16:12:40 MST." <20021125161239.A20831@home.com>


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/

  parent reply	other threads:[~2002-11-25 23:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-25 22:13 PPC RTC on I2C Montgomery, Tim
2002-11-25 22:43 ` "Extra cflags for kbuild 2.4." [ _devel tree ] Mark Pilon
2002-11-25 23:12 ` PPC RTC on I2C Matt Porter
2002-11-25 23:06   ` Dan Malek
2002-11-25 23:07   ` Wolfgang Denk [this message]
2002-11-26  8:09     ` Joakim Tjernlund
2002-11-26  8:23 ` leeyang
2002-12-02 10:38   ` QMC driver for 860? Joakim Tjernlund
2002-12-02 12:41     ` Pantelis Antoniou
2002-12-02 13:18       ` Joakim Tjernlund

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021125230731.43D9DC58BF@atlas.denx.de \
    --to=wd@denx.de \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=porter@cox.net \
    --cc=timm@artesyncp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox