Hi,
this is my second try to send this patch, in the previous attempts
I goofed up somehow and mail got duplicated. That's my first patch
to LKML, so please bear with me ;)
The patch attached adds support for the Epson 8564 RTC chip. This
is a RTC chip sitting on the I2C bus. AFAIK the chip's address is
hardcoded in silicon.
This driver only does the low-level I2C stuff, the rtc misc device
driver is a separate driver module which I will send a patch for soon.
I CC Greg KH because its I2C, as Andrew Morton told me to do.
The patch is against 2.6.6-rc3, but should apply cleanly to other
2.6 kernels.
Please comment,
Stefan E.
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
Hi Stefan,
> This driver only does the low-level I2C stuff, the rtc misc device
> driver is a separate driver module which I will send a patch for soon.
I have a patch (attached, it could do with cleaning up) for the Dallas
DS1307 I2C RTC which I ported from the 2.4 rmk patch, originally written
by Intrinsyc. Currently it includes both the I2C and the RTC bits in the
same driver.
Do you think it is realistic/possible to have the same generic RTC
driver speak to multiple I2C devices, from what I can see in your driver
the two chips seem pretty similar and the differences could probably be
abstracted away. Perhaps that is your intention from the start?
I guess I will wait until you post the RTC misc driver and try and make
the DS1307 one work with that before I submit it.
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
On Thu, Apr 29, 2004 at 01:41:23PM +0100, Ian Campbell wrote:
> Hi Stefan,
>
> > This driver only does the low-level I2C stuff, the rtc misc device
> > driver is a separate driver module which I will send a patch for soon.
>
> I have a patch (attached, it could do with cleaning up) for the Dallas
> DS1307 I2C RTC which I ported from the 2.4 rmk patch, originally written
> by Intrinsyc. Currently it includes both the I2C and the RTC bits in the
> same driver.
Have a look at drivers/acorn/char/{i2c,pcf8583}.[ch]
> Do you think it is realistic/possible to have the same generic RTC
> driver speak to multiple I2C devices, from what I can see in your driver
> the two chips seem pretty similar and the differences could probably be
> abstracted away. Perhaps that is your intention from the start?
>
> I guess I will wait until you post the RTC misc driver and try and make
> the DS1307 one work with that before I submit it.
If you look at the last 2.6-rmk patch, you'll notice that it contains
an abstracted RTC driver - I got peed off with writing the same code
to support the user interfaces to the variety of RTCs over and over
again. (Ones which are simple 32-bit second counters with alarms
through to ones which return D/M/Y H:M:S.C format.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Thu, 2004-04-29 at 13:02, [email protected] wrote:
> This driver only does the low-level I2C stuff, the rtc misc device
> driver is a separate driver module which I will send a patch for soon.
By the way -- I notice you have said you need i2c_get_client for your
RTC driver to locate the i2c chip it wants to work with.
Just a thought -- perhaps it would make sense to reverse the roles and
for the rtc driver to export a 'register_rtc_device' type call which the
specific i2c chip driver could then call to hook itself up to /dev/rtc
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
On Thu, Apr 29, 2004 at 01:59:40PM +0100, Ian Campbell wrote:
> On Thu, 2004-04-29 at 13:02, [email protected] wrote:
> > This driver only does the low-level I2C stuff, the rtc misc device
> > driver is a separate driver module which I will send a patch for soon.
>
> By the way -- I notice you have said you need i2c_get_client for your
> RTC driver to locate the i2c chip it wants to work with.
Correct. I'll send a patch which re-adds this call to 2.6.6-rcx.
>
> Just a thought -- perhaps it would make sense to reverse the roles and
> for the rtc driver to export a 'register_rtc_device' type call which the
> specific i2c chip driver could then call to hook itself up to /dev/rtc
The problem with this approach is IHMO that you need the i2c_client struct in
I2C chrip driver as well (to call the i2c access primitives). You'd need to
store the pointer to the client somewhere in the driver itself. What if we have
more than one client per driver?
IMHO the call i2c_get_client() is nice and clean. One could wish another call like
int i2c_command( struct i2c_client *c, long cmd, void *arg );
whcih does a
client->driver->command( client, cmd, arg );
internally.
>
> Ian.
>
> --
> Ian Campbell, Senior Design Engineer
> Web: http://www.arcom.com
> Arcom, Clifton Road, Direct: +44 (0)1223 403 465
> Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
>
>
> _____________________________________________________________________
> The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
>
> This message has been virus scanned by MessageLabs.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
On Thu, Apr 29, 2004 at 01:54:08PM +0100, Russell King wrote:
> On Thu, Apr 29, 2004 at 01:41:23PM +0100, Ian Campbell wrote:
> > Hi Stefan,
> >
> > > This driver only does the low-level I2C stuff, the rtc misc device
> > > driver is a separate driver module which I will send a patch for soon.
> >
> > I have a patch (attached, it could do with cleaning up) for the Dallas
> > DS1307 I2C RTC which I ported from the 2.4 rmk patch, originally written
> > by Intrinsyc. Currently it includes both the I2C and the RTC bits in the
> > same driver.
>
> Have a look at drivers/acorn/char/{i2c,pcf8583}.[ch]
>
> > Do you think it is realistic/possible to have the same generic RTC
> > driver speak to multiple I2C devices, from what I can see in your driver
> > the two chips seem pretty similar and the differences could probably be
> > abstracted away. Perhaps that is your intention from the start?
> >
> > I guess I will wait until you post the RTC misc driver and try and make
> > the DS1307 one work with that before I submit it.
>
> If you look at the last 2.6-rmk patch, you'll notice that it contains
> an abstracted RTC driver - I got peed off with writing the same code
> to support the user interfaces to the variety of RTCs over and over
> again. (Ones which are simple 32-bit second counters with alarms
> through to ones which return D/M/Y H:M:S.C format.)
Oh, I wasn't aware of that. I assume that one is not in linus bk tree already?
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
> 2.6 Serial core
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
On Thu, 2004-04-29 at 14:58, [email protected] wrote:
> On Thu, Apr 29, 2004 at 01:54:08PM +0100, Russell King wrote:
> > If you look at the last 2.6-rmk patch, you'll notice that it contains
> > an abstracted RTC driver - I got peed off with writing the same code
> > to support the user interfaces to the variety of RTCs over and over
> > again. (Ones which are simple 32-bit second counters with alarms
> > through to ones which return D/M/Y H:M:S.C format.)
>
> Oh, I wasn't aware of that. I assume that one is not in linus bk tree already?
I don't think so. I found it in patch-2.6.0-test9-rmk1. In particular
arch/arm/common/rtctime.c and include/asm-arm/rtc.h which implement the
generic RTC bit. drivers/char/sa1100-rtc.c and
linux/arch/arm/mach-integrator/time.c have been ported to use it.
It looks very useful, and it would be pretty easy to make an i2c RTC use
it as well.
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
On Thu, Apr 29, 2004 at 03:14:24PM +0100, Ian Campbell wrote:
> On Thu, 2004-04-29 at 14:58, [email protected] wrote:
> > On Thu, Apr 29, 2004 at 01:54:08PM +0100, Russell King wrote:
> > > If you look at the last 2.6-rmk patch, you'll notice that it contains
> > > an abstracted RTC driver - I got peed off with writing the same code
> > > to support the user interfaces to the variety of RTCs over and over
> > > again. (Ones which are simple 32-bit second counters with alarms
> > > through to ones which return D/M/Y H:M:S.C format.)
> >
> > Oh, I wasn't aware of that. I assume that one is not in linus bk tree already?
>
> I don't think so. I found it in patch-2.6.0-test9-rmk1. In particular
> arch/arm/common/rtctime.c and include/asm-arm/rtc.h which implement the
> generic RTC bit. drivers/char/sa1100-rtc.c and
> linux/arch/arm/mach-integrator/time.c have been ported to use it.
>
> It looks very useful, and it would be pretty easy to make an i2c RTC use
> it as well.
Ah, haven't had a look at 2.6.0-test9 for some time now. I'll try to check
these and maybe I'll port my rtc driver over to it. Maybe these files
sould be moved out of the arm tree, though? It may well be that other platforms
are interested it (at last I've found a drivers/char/genrtc.c ...).
>
> Ian.
> --
> Ian Campbell, Senior Design Engineer
> Web: http://www.arcom.com
> Arcom, Clifton Road, Direct: +44 (0)1223 403 465
> Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
>
>
> _____________________________________________________________________
> The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
>
> This message has been virus scanned by MessageLabs.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
On Thu, Apr 29, 2004 at 01:54:08PM +0100, Russell King wrote:
> On Thu, Apr 29, 2004 at 01:41:23PM +0100, Ian Campbell wrote:
> > Hi Stefan,
> >
> > > This driver only does the low-level I2C stuff, the rtc misc device
> > > driver is a separate driver module which I will send a patch for soon.
> >
> > I have a patch (attached, it could do with cleaning up) for the Dallas
> > DS1307 I2C RTC which I ported from the 2.4 rmk patch, originally written
> > by Intrinsyc. Currently it includes both the I2C and the RTC bits in the
> > same driver.
>
> Have a look at drivers/acorn/char/{i2c,pcf8583}.[ch]
>
> > Do you think it is realistic/possible to have the same generic RTC
> > driver speak to multiple I2C devices, from what I can see in your driver
> > the two chips seem pretty similar and the differences could probably be
> > abstracted away. Perhaps that is your intention from the start?
> >
> > I guess I will wait until you post the RTC misc driver and try and make
> > the DS1307 one work with that before I submit it.
>
> If you look at the last 2.6-rmk patch, you'll notice that it contains
> an abstracted RTC driver - I got peed off with writing the same code
> to support the user interfaces to the variety of RTCs over and over
> again. (Ones which are simple 32-bit second counters with alarms
> through to ones which return D/M/Y H:M:S.C format.)
A generic one for i2c rtcs or another generic rtc driver? There's
already drivers/char/genrtc.c...
--
Tom Rini
http://gate.crashing.org/~trini/
On Thu, Apr 29, 2004 at 03:40:07PM -0700, Tom Rini wrote:
> A generic one for i2c rtcs or another generic rtc driver? There's
> already drivers/char/genrtc.c...
genrtc.c lacks several features ARM needs, the big one being wakeup
timers. It also only provides either (configurable) emulation or no
support of various RTC features, rather than allowing a real RTC to
provide them if it can - and you need to know the details of your RTC
at kernel configuration time.
It provides no support for translating "RTC" time into seconds and
vice versa which is needed for second-counter based RTCs found in
PXA, StrongARM, and other ARM SoC platforms.
IOW, its fairly restrictive in what it provides and what it allows
architectures to provide.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Thu, Apr 29, 2004 at 11:49:45PM +0100, Russell King wrote:
> On Thu, Apr 29, 2004 at 03:40:07PM -0700, Tom Rini wrote:
> > A generic one for i2c rtcs or another generic rtc driver? There's
> > already drivers/char/genrtc.c...
>
> genrtc.c lacks several features ARM needs, the big one being wakeup
> timers. It also only provides either (configurable) emulation or no
> support of various RTC features, rather than allowing a real RTC to
> provide them if it can - and you need to know the details of your RTC
> at kernel configuration time.
Having hacked at this, and just not having had the time to clean it up a
bit more yet, did you try adding it to genrtc at least?
> It provides no support for translating "RTC" time into seconds and
> vice versa which is needed for second-counter based RTCs found in
> PXA, StrongARM, and other ARM SoC platforms.
It couldn't be added in?
> IOW, its fairly restrictive in what it provides and what it allows
> architectures to provide.
Either way, I'd like to not have 2 generic rtc drivers if at all
possible...
--
Tom Rini
http://gate.crashing.org/~trini/
On Thu, Apr 29, 2004 at 03:52:38PM -0700, Tom Rini wrote:
> Either way, I'd like to not have 2 generic rtc drivers if at all
> possible...
So would I...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core