All of lore.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: David Brownell <david-b@pacbell.net>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	rtc-linux@googlegroups.com, "Brown, Len" <len.brown@intel.com>
Subject: Re: [patch 2.6.20-rc3 3/3] export ACPI info to rtc_cmos platform data
Date: Wed, 24 Jan 2007 23:07:10 -0500	[thread overview]
Message-ID: <200701242307.10791.lenb@kernel.org> (raw)
In-Reply-To: <200701051003.43808.david-b@pacbell.net>

Eventually we may bundle ACPI/PNP/PNPACPI, so the #else !CONFIG_PNPACPI part
here can go away.

Acked-by: Len Brown <len.brown@intel.com>

On Friday 05 January 2007 13:03, David Brownell wrote:
> Update ACPI to export its RTC extension information through platform_data
> to the PNPACPI or platform bus device node used on the system being set up.
> 
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> 
> ====
>  drivers/acpi/glue.c |   89 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 89 insertions(+)
> 
> This will probably need to be updated later to provide a firmware hook
> to handle system suspend with an alarm pending, with ACPI_EVENT_RTC.
> The same hook could eventually need to handle EFI.
> 
> Index: g26/drivers/acpi/glue.c
> ===================================================================
> --- g26.orig/drivers/acpi/glue.c	2007-01-02 20:05:31.000000000 -0800
> +++ g26/drivers/acpi/glue.c	2007-01-02 23:35:44.000000000 -0800
> @@ -364,3 +364,92 @@ 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".  Here we find
> + * its device node and pass extra config data.  This helps its driver use
> + * capabilities that the now-obsolete mc146818 didn't have, and informs it
> + * that this board's RTC is wakeup-capable (per ACPI spec).
> + */
> +#include <linux/mc146818rtc.h>
> +
> +static struct cmos_rtc_board_info rtc_info;
> +
> +
> +#ifdef CONFIG_PNPACPI
> +
> +/* PNP devices are registered in a subsys_initcall();
> + * ACPI specifies the PNP IDs to use.
> + */
> +#include <linux/pnp.h>
> +
> +static int __init pnp_match(struct device *dev, void *data)
> +{
> +	static const char *ids[] = { "PNP0b00", "PNP0b01", "PNP0b02", };
> +	struct pnp_dev *pnp = to_pnp_dev(dev);
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(ids); i++) {
> +		if (compare_pnp_id(pnp->id, ids[i]) != 0)
> +			return 1;
> +	}
> +	return 0;
> +}
> +
> +static struct device *__init get_rtc_dev(void)
> +{
> +	return bus_find_device(&pnp_bus_type, NULL, NULL, pnp_match);
> +}
> +
> +#else
> +
> +/* We expect non-PNPACPI platforms to register an RTC device, usually
> + * at or near arch_initcall().  That also helps for example PCs that
> + * aren't configured with ACPI (where this code wouldn't run, but the
> + * RTC would still be available).  The device name matches the driver;
> + * that's how the platform bus works.
> + */
> +#include <linux/platform_device.h>
> +
> +static int __init platform_match(struct device *dev, void *data)
> +{
> +	struct platform_device	*pdev;
> +
> +	pdev = container_of(dev, struct platform_device, dev);
> +	return strcmp(pdev->name, "rtc_cmos") == 0;
> +}
> +
> +static struct device *__init get_rtc_dev(void)
> +{
> +	return bus_find_device(&platform_bus_type, NULL, NULL, platform_match);
> +}
> +
> +#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;
> +
> +		/* NOTE:  acpi_gbl_FADT->rtcs4 is currently useful */
> +
> +		dev->platform_data = &rtc_info;
> +
> +		/* RTC always wakes from S1/S2/S3, and often S4/STD */
> +		device_init_wakeup(dev, 1);
> +
> +		put_device(dev);
> +	} else
> +		pr_debug("ACPI: RTC unavailable?\n");
> +	return 0;
> +}
> +/* do this between RTC subsys_initcall() and rtc_cmos driver_initcall() */
> +fs_initcall(acpi_rtc_init);
> +
> +#endif
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

      reply	other threads:[~2007-01-25  4:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-05 18:03 [patch 2.6.20-rc3 3/3] export ACPI info to rtc_cmos platform data David Brownell
2007-01-25  4:07 ` Len Brown [this message]

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=200701242307.10791.lenb@kernel.org \
    --to=lenb@kernel.org \
    --cc=alessandro.zummo@towertech.it \
    --cc=david-b@pacbell.net \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rtc-linux@googlegroups.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 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.