* PPC RTC on I2C
@ 2002-11-25 22:13 Montgomery, Tim
2002-11-25 22:43 ` "Extra cflags for kbuild 2.4." [ _devel tree ] Mark Pilon
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Montgomery, Tim @ 2002-11-25 22:13 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread* "Extra cflags for kbuild 2.4." [ _devel tree ]
2002-11-25 22:13 PPC RTC on I2C Montgomery, Tim
@ 2002-11-25 22:43 ` Mark Pilon
2002-11-25 23:12 ` PPC RTC on I2C Matt Porter
2002-11-26 8:23 ` leeyang
2 siblings, 0 replies; 13+ messages in thread
From: Mark Pilon @ 2002-11-25 22:43 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: PPC RTC on I2C
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 ` Matt Porter
2002-11-25 23:06 ` Dan Malek
2002-11-25 23:07 ` Wolfgang Denk
2002-11-26 8:23 ` leeyang
2 siblings, 2 replies; 13+ messages in thread
From: Matt Porter @ 2002-11-25 23:12 UTC (permalink / raw)
To: Montgomery, Tim; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: PPC RTC on I2C
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
1 sibling, 0 replies; 13+ messages in thread
From: Dan Malek @ 2002-11-25 23:06 UTC (permalink / raw)
To: Matt Porter; +Cc: Montgomery, Tim, linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: PPC RTC on I2C
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
2002-11-26 8:09 ` Joakim Tjernlund
1 sibling, 1 reply; 13+ messages in thread
From: Wolfgang Denk @ 2002-11-25 23:07 UTC (permalink / raw)
To: Matt Porter; +Cc: Montgomery, Tim, linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: PPC RTC on I2C
2002-11-25 23:07 ` Wolfgang Denk
@ 2002-11-26 8:09 ` Joakim Tjernlund
0 siblings, 0 replies; 13+ messages in thread
From: Joakim Tjernlund @ 2002-11-26 8:09 UTC (permalink / raw)
To: Wolfgang Denk, Matt Porter; +Cc: Montgomery, Tim, linuxppc-embedded
> [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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: PPC RTC on I2C
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-26 8:23 ` leeyang
2002-12-02 10:38 ` QMC driver for 860? Joakim Tjernlund
2 siblings, 1 reply; 13+ messages in thread
From: leeyang @ 2002-11-26 8:23 UTC (permalink / raw)
To: Montgomery, Tim; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* QMC driver for 860?
2002-11-26 8:23 ` leeyang
@ 2002-12-02 10:38 ` Joakim Tjernlund
2002-12-02 12:41 ` Pantelis Antoniou
0 siblings, 1 reply; 13+ messages in thread
From: Joakim Tjernlund @ 2002-12-02 10:38 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: QMC driver for 860?
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
0 siblings, 1 reply; 13+ messages in thread
From: Pantelis Antoniou @ 2002-12-02 12:41 UTC (permalink / raw)
To: joakim.tjernlund, linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: QMC driver for 860?
2002-12-02 12:41 ` Pantelis Antoniou
@ 2002-12-02 13:18 ` Joakim Tjernlund
0 siblings, 0 replies; 13+ messages in thread
From: Joakim Tjernlund @ 2002-12-02 13:18 UTC (permalink / raw)
To: Pantelis Antoniou, linuxppc-embedded
> >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/
^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <3DEB676E.7090507@intracom.gr>]
* RE: QMC driver for 860?
[not found] <3DEB676E.7090507@intracom.gr>
@ 2002-12-02 15:09 ` Joakim Tjernlund
2002-12-02 15:21 ` Pantelis Antoniou
0 siblings, 1 reply; 13+ messages in thread
From: Joakim Tjernlund @ 2002-12-02 15:09 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
> OK
>
> You asked for it ;).
>
> The file netvia_tsa.c is the actual QMC + stuff driver.
> The file netvia_bri.c is an example driver.
> The header files are the QMC definitions.
>
> Linux kernel version is 2.4.20.
>
> Don't hesitate to ask for any explanations.
>
> Pantelis
Thanks a lot!
I have just browsed the driver and I noticed that there is room for performance
improvements in netvia_tsa.c w.r.t memcpy(). You can avoid the memcpy() call
for received packets by using invalidate_dcache_range(). I did this for
the 8xx_io/enet.c driver a few weeks ago(it's not in BK yet).
See http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html
and
http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html
Jocke
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: QMC driver for 860?
2002-12-02 15:09 ` Joakim Tjernlund
@ 2002-12-02 15:21 ` Pantelis Antoniou
2002-12-02 17:11 ` Joakim Tjernlund
0 siblings, 1 reply; 13+ messages in thread
From: Pantelis Antoniou @ 2002-12-02 15:21 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
Joakim Tjernlund wrote:
>>OK
>>
>>You asked for it ;).
>>
>>The file netvia_tsa.c is the actual QMC + stuff driver.
>>The file netvia_bri.c is an example driver.
>>The header files are the QMC definitions.
>>
>>Linux kernel version is 2.4.20.
>>
>>Don't hesitate to ask for any explanations.
>>
>>Pantelis
>>
>>
>
>Thanks a lot!
>
>I have just browsed the driver and I noticed that there is room for performance
>improvements in netvia_tsa.c w.r.t memcpy(). You can avoid the memcpy() call
>for received packets by using invalidate_dcache_range(). I did this for
>the 8xx_io/enet.c driver a few weeks ago(it's not in BK yet).
>
>See http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html
>and
>http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html
>
> Jocke
>
>
>
>
>
Yes, I know the trick. I'm looking forward to see your changes
make it in. As it stands I'm not tracking the BK PPC tree, but
the Linus tree. Being behind the company firewall, BK is not
very useful.
In this driver case since I'm reading the packet in a non-cachable
area, and not directly in a skb, I'm not convinced that
the invalidate_dcache_range will be a great win.
If you do any performance testing I'm very interested in
your results.
Pantelis
P.S. Is there anyone in the list interested in this?
Should I clean it up, and submit it?
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: QMC driver for 860?
2002-12-02 15:21 ` Pantelis Antoniou
@ 2002-12-02 17:11 ` Joakim Tjernlund
0 siblings, 0 replies; 13+ messages in thread
From: Joakim Tjernlund @ 2002-12-02 17:11 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
>
> Joakim Tjernlund wrote:
>
> >>OK
> >>
> >>You asked for it ;).
> >>
> >>The file netvia_tsa.c is the actual QMC + stuff driver.
> >>The file netvia_bri.c is an example driver.
> >>The header files are the QMC definitions.
> >>
> >>Linux kernel version is 2.4.20.
> >>
> >>Don't hesitate to ask for any explanations.
> >>
> >>Pantelis
> >>
> >>
> >
> >Thanks a lot!
> >
> >I have just browsed the driver and I noticed that there is room for performance
> >improvements in netvia_tsa.c w.r.t memcpy(). You can avoid the memcpy() call
> >for received packets by using invalidate_dcache_range(). I did this for
> >the 8xx_io/enet.c driver a few weeks ago(it's not in BK yet).
> >
> >See http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html
> >and
> >http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html
> >
> > Jocke
> >
> Yes, I know the trick. I'm looking forward to see your changes
> make it in. As it stands I'm not tracking the BK PPC tree, but
> the Linus tree. Being behind the company firewall, BK is not
> very useful.
The patch should apply to linus tree as well. There is just a small bug
in my second version(the invalidate_dcache_range() call must be moved).
>
> In this driver case since I'm reading the packet in a non-cachable
> area, and not directly in a skb, I'm not convinced that
> the invalidate_dcache_range will be a great win.
It should be a win since the patch removes the need for non-cachable memory and a
memcpy()(only add a invalidate_dcache_range call for non cache coherent CPUs like the 8xx).
Jocke
>
> If you do any performance testing I'm very interested in
> your results.
>
> Pantelis
>
> P.S. Is there anyone in the list interested in this?
> Should I clean it up, and submit it?
Is QMC supported on other families than 8xx? If so I think it would be a good idea.
The 862 even has the QMC built in so there must be a need for this.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-12-02 17:11 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
[not found] <3DEB676E.7090507@intracom.gr>
2002-12-02 15:09 ` Joakim Tjernlund
2002-12-02 15:21 ` Pantelis Antoniou
2002-12-02 17:11 ` Joakim Tjernlund
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox