From: Mark Zhan <hidden> Date: 2007-06-11 11:55:50
Add the support of ST M48T59 RTC chip driver in RTC class subsystem for
Wind River SBC PowerQUICCII 82xx board
Signed-off-by: Mark Zhan <redacted>
---
b/drivers/rtc/Kconfig | 10 +
b/drivers/rtc/Makefile | 1
b/drivers/rtc/rtc-m48t59.c | 360
+++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 371 insertions(+)
On Mon, 11 Jun 2007 15:56:40 +0800
Mark Zhan [off-list ref] wrote:
Add the support of ST M48T59 RTC chip driver in RTC class subsystem for
Wind River SBC PowerQUICCII 82xx board
Hello Mark, thanks for you contribution. Code looks
good, I only have some minor comments:
+config RTC_DRV_M48T59
+ tristate "ST M48T59"
+ depends on RTC_CLASS
+ help
+ If you say Y here you will get support for the
+ ST M48T59 RTC chip.
+
+ This driver can also be built as a module, if so, the module
+ will be called "rtc-m48t59".
Please add some infos about the Wind River board in the help.
this is going to be deprecated, you can use it but it will fade away
sooner or later. you might want to add a sysfs attribute
with the battery info.
thanks.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
From: Gabriel Paubert <hidden> Date: 2007-06-11 12:11:53
On Mon, Jun 11, 2007 at 03:56:40PM +0800, Mark Zhan wrote:
Add the support of ST M48T59 RTC chip driver in RTC class subsystem for
Wind River SBC PowerQUICCII 82xx board
There are other boards which have exactly the same chip, but use
a very different (uglier) access method: using ISA 2 I/O ports
(0x74 and 0x75) to write the address and another port (0x77) to
read/write the data.
Besides that, these boards also use the NVRAM part which means that
a spinlock must be used to serialize between RTC and NVRAM access.
I have no idea whether the drivers should be shared or two
different drivers should be written... But if there are two
different drivers, there should be a way to distinguish them
(different config name, different module names, and some
explanation in the config help text).
Another style is to put the flag and control register values
immediately after the register, indenting the values an additional tab
to distinguish them from the list of registers. Either way is ok with
me.
+ /* Clear the READ bit to restore the update */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) & ~0x40), M48T59_CNTL);
Should you clear READ and WRITE when your driver starts in case the
previous driver got interrupted (say the system crashed)? Or is it ok
for READ and WRITE to be set?
You aren't using the READ and WRITE flag bits you defined above. If
the line gets too long, you might create a SET_BITS / CLEAR_BITS macro.
milton
From: Mark Zhan <hidden> Date: 2007-06-12 14:00:05
Hi Gabriel,
On Mon, 2007-06-11 at 14:11 +0200, Gabriel Paubert wrote:
....
There are other boards which have exactly the same chip, but use
a very different (uglier) access method: using ISA 2 I/O ports
(0x74 and 0x75) to write the address and another port (0x77) to
read/write the data.
Besides that, these boards also use the NVRAM part which means that
a spinlock must be used to serialize between RTC and NVRAM access.
I have no idea whether the drivers should be shared or two
different drivers should be written... But if there are two
different drivers, there should be a way to distinguish them
(different config name, different module names, and some
explanation in the config help text).
I will rework this driver to add a platform data structure which enables
the platform to provide the platform specific access method.
For the NVRAM issue, I have no idea how other boards access the NVRAM.
So could you provide me more information?
From: Mark Zhan <hidden> Date: 2007-06-12 14:13:03
Hi All,
For the platform data of RTC chip driver, you know, currently we use
different header files to define different driver-specific platform data
structure. For example: linux/m48t86.h, linux/rtc-v3020.h....
Could we consider to add a new header file linux/rtc_pd.h to gather them
together, and remove those rtc platform data header files in
include/linux directory?
Thanks
Mark Zhan
On Tue, 2007-06-12 at 21:59 +0800, Mark Zhan wrote:
Hi Gabriel,
On Mon, 2007-06-11 at 14:11 +0200, Gabriel Paubert wrote:
....
quoted
There are other boards which have exactly the same chip, but use
a very different (uglier) access method: using ISA 2 I/O ports
(0x74 and 0x75) to write the address and another port (0x77) to
read/write the data.
Besides that, these boards also use the NVRAM part which means that
a spinlock must be used to serialize between RTC and NVRAM access.
I have no idea whether the drivers should be shared or two
different drivers should be written... But if there are two
different drivers, there should be a way to distinguish them
(different config name, different module names, and some
explanation in the config help text).
I will rework this driver to add a platform data structure which enables
the platform to provide the platform specific access method.
For the NVRAM issue, I have no idea how other boards access the NVRAM.
So could you provide me more information?
Shouldn't it be NO_IRQ (here and in several other places) ?
Yeah, agree. I will modify it.
Thanks your comment.
Best Regards
Mark Zhan
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Gabriel Paubert <hidden> Date: 2007-06-14 10:32:14
On Tue, Jun 12, 2007 at 09:59:36PM +0800, Mark Zhan wrote:
Hi Gabriel,
On Mon, 2007-06-11 at 14:11 +0200, Gabriel Paubert wrote:
....
quoted
There are other boards which have exactly the same chip, but use
a very different (uglier) access method: using ISA 2 I/O ports
(0x74 and 0x75) to write the address and another port (0x77) to
read/write the data.
Besides that, these boards also use the NVRAM part which means that
a spinlock must be used to serialize between RTC and NVRAM access.
I have no idea whether the drivers should be shared or two
different drivers should be written... But if there are two
different drivers, there should be a way to distinguish them
(different config name, different module names, and some
explanation in the config help text).
I will rework this driver to add a platform data structure which enables
the platform to provide the platform specific access method.
I'm not even sure that this is a good idea: the direct mapped nvram/RTC
is much simpler, and adding another indirection layer transforms many
leaf functions into non leaf one, which makes the code significantly bigger.
For the NVRAM issue, I have no idea how other boards access the NVRAM.
So could you provide me more information?
That's the hardest problem. Since you use the same ISA (yuck) I/O
ports to access the NVRAM and the RTC (after all it is the same chip,
using the same address pins), the accesses need to be serialized
through a shared spinlock.
With a direct mapped like your machine, the drivers can be completely
independent: they will never step on each other's toes.
I've not yet made up my mind on which is the best way to handle
the problem and am leaving tomorrow for about 1 week. For
now I think that your patch is fine (using NO_IRQ as I suggested)
and I shall revisit it when time comes to port the kernel
to these boards (running 2.2 for 8 years, it's not a few
more months to switch to 2.6 that matters).
Regards,
Gabriel
On Tue, 12 Jun 2007 22:12:25 +0800
Mark Zhan [off-list ref] wrote:
Hi All,
For the platform data of RTC chip driver, you know, currently we use
different header files to define different driver-specific platform data
structure. For example: linux/m48t86.h, linux/rtc-v3020.h....
Could we consider to add a new header file linux/rtc_pd.h to gather them
together, and remove those rtc platform data header files in
include/linux directory?
files in linux/ are the ones that are required by other modules
of the kernel and it wouldn't be fair to combine all of them.
I'd rather add a linux/rtc directory.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it