All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Alessandro Zummo <alessandro.zummo@towertech.it>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	Len Brown <lenb@kernel.org>
Subject: [patch 2.6.19-rc6 4/6] ACPI exports RTC extensions through platform_data
Date: Mon, 20 Nov 2006 10:27:34 -0800	[thread overview]
Message-ID: <200611201027.34641.david-b@pacbell.net> (raw)
In-Reply-To: <200611201014.41980.david-b@pacbell.net>

Define platform_data for the MC146818 based RTCs, currently just holding
extensions standardized by ACPI (but available on some ACPI-neutral clones).

Update ACPI to export that RTC extension information through platform_data
to the PNP or platform bus device node.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Index: g26/include/linux/mc146818rtc.h
===================================================================
--- g26.orig/include/linux/mc146818rtc.h	2006-11-20 10:03:06.000000000 -0800
+++ g26/include/linux/mc146818rtc.h	2006-11-20 10:10:45.000000000 -0800
@@ -18,6 +18,18 @@
 #ifdef __KERNEL__
 #include <linux/spinlock.h>		/* spinlock_t */
 extern spinlock_t rtc_lock;		/* serialize CMOS RAM access */
+
+/* Some RTCs extend the mc146818 register set to support alarms of more
+ * than 24 hours in the future; or dates that include a century code.
+ * And sometimes the RTC alarm can wake the system from suspend-to-disk.
+ * This platform_data structure can pass this information to the driver.
+ */
+struct cmos_rtc_board_info {
+	u8	rtc_day_alarm;		/* zero, or register index */
+	u8	rtc_mon_alarm;		/* zero, or register index */
+	u8	rtc_century;		/* zero, or register index */
+	u8	wake_from_std;		/* true iff alarm wakes from STD */
+};
 #endif
 
 /**********************************************************************
Index: g26/drivers/acpi/glue.c
===================================================================
--- g26.orig/drivers/acpi/glue.c	2006-11-20 10:03:06.000000000 -0800
+++ g26/drivers/acpi/glue.c	2006-11-20 10:10:45.000000000 -0800
@@ -358,3 +358,107 @@ static int __init init_acpi_device_notif
 }
 
 arch_initcall(init_acpi_device_notify);
+
+
+#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE)
+
+/* Every ACPI platform has a mc146818 compatible "cmos rtc".  We want
+ * to find its device node, so we can pass ACPI-specific config data
+ * to its driver.  So we'll just probe for that device -- with a dummy
+ * driver, using the relevant bus -- before the RTC driver initializes.
+ */
+#include <linux/mc146818rtc.h>
+
+static struct cmos_rtc_board_info rtc_info;
+
+static struct device *rtc_dev __initdata;
+static char drvname[] __initdata = "rtc_cmos";
+
+
+#ifdef CONFIG_PNPACPI
+
+/* PNP devices are registered in a subsys_initcall();
+ * ACPI specifies the PNP IDs to use.
+ */
+#include <linux/pnp.h>
+
+static struct pnp_device_id rtc_ids[] __initdata = {
+	{ .id = "PNP0b00", },
+	{ .id = "PNP0b01", },
+	{ .id = "PNP0b02", },
+	{ },
+};
+
+static int __init
+rtc_pnp_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
+{
+	rtc_dev = &pnp->dev;
+	return -ENXIO;
+}
+
+static struct pnp_driver cmos_pnp_driver __initdata = {
+	.name		= drvname,
+	.id_table	= rtc_ids,
+	.probe		= rtc_pnp_probe,
+};
+
+static struct device *__init get_rtc_dev(void)
+{
+	if (pnp_register_driver(&cmos_pnp_driver) == 0)
+		pnp_unregister_driver(&cmos_pnp_driver);
+	return rtc_dev;
+}
+
+#else
+
+/* We expect platforms to register an RTC device, conventionally at or
+ * near arch_initcall().  That should work even without ACPI.  The driver
+ * name matters; it must match the driver.
+ */
+#include <linux/platform_device.h>
+
+static int __init rtc_platform_probe(struct platform_device *pdev)
+{
+	rtc_dev = &pdev->dev;
+	return -ENXIO;
+}
+
+static struct platform_driver rtc_platform_driver __initdata = {
+	.driver = {
+		.name		= drvname,
+	},
+	.probe		= rtc_platform_probe,
+};
+
+static struct device *__init get_rtc_dev(void)
+{
+	if (platform_driver_register(&rtc_platform_driver) == 0)
+		platform_driver_unregister(&rtc_platform_driver);
+	return rtc_dev;
+}
+
+#endif
+
+static int __init acpi_rtc_init(void)
+{
+	struct device *dev = get_rtc_dev();
+
+	if (dev) {
+		rtc_info.rtc_day_alarm = acpi_gbl_FADT->day_alrm;
+		rtc_info.rtc_mon_alarm = acpi_gbl_FADT->mon_alrm;
+		rtc_info.rtc_century = acpi_gbl_FADT->century;
+
+		/* REVISIT iff revision > FADT2_REVISION_ID ? */
+		rtc_info.wake_from_std = acpi_gbl_FADT->rtcs4;
+
+		dev->platform_data = &rtc_info;
+
+		/* RTC always wakes from S1/S2/S3, and often S4/STD */
+		device_init_wakeup(dev, 1);
+	} else
+		pr_debug("ACPI: RTC unavailable?\n");
+	return 0;
+}
+fs_initcall(acpi_rtc_init);
+
+#endif


  parent reply	other threads:[~2006-11-20 22:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-20 18:14 [patch 2.6.19-rc6 0/6] more rtc framework/driver updates David Brownell
2006-11-20 18:17 ` [patch 2.6.19-rc6 1/6] rtc class /proc/driver/rtc update David Brownell
2006-11-20 23:13   ` Alessandro Zummo
2006-11-21  2:47     ` [Bulk] " David Brownell
2006-11-22 20:37       ` Alessandro Zummo
2006-11-23  0:39         ` David Brownell
2006-11-20 18:19 ` [patch 2.6.19-rc6 2/6] rtc-sa1100 tweaks David Brownell
2006-11-20 22:48   ` Russell King
2006-11-21  1:46     ` David Brownell
2006-11-20 18:22 ` [patch 2.6.19-rc6 3/6] X86_PC optionally creates rtc_cmos platform device David Brownell
2006-11-20 18:27 ` [patch 2.6.19-rc6 5/6] rtc-cmos driver David Brownell
2006-11-20 18:27 ` David Brownell [this message]
2006-11-20 18:28 ` [patch 2.6.19-rc6 6/6] rtc-omap driver David Brownell
2006-11-20 23:09   ` Alessandro Zummo
2006-11-22  1:19   ` Andrew Morton
2006-11-22  2:15     ` David Brownell
2006-11-22  2:28       ` Andrew Morton
2006-11-23  0:09         ` David Brownell
2006-11-22 20:34       ` Alessandro Zummo

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=200611201027.34641.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=alessandro.zummo@towertech.it \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.