mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Hanjun Guo <hanjun.guo@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Olof Johansson <olof@lixom.net>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	Jon Masters <jonathan@jonmasters.org>,
	"patches@linaro.org" <patches@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	Amit Daniel Kachhap <amit.daniel@samsung.com>
Subject: Re: [RFC part3 PATCH 1/2] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer
Date: Tue, 3 Dec 2013 17:04:07 +0000	[thread overview]
Message-ID: <20131203170407.GA16025@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <1386088891-2917-2-git-send-email-hanjun.guo@linaro.org>

On Tue, Dec 03, 2013 at 04:41:30PM +0000, Hanjun Guo wrote:
> ACPI GTDT (Generic Timer Description Table) contains information for
> arch timer initialization, this patch use this table to probe arm timer.
> 
> GTDT table is used for ARM/ARM64 only, please refer to chapter 5.2.24
> of ACPI 5.0 spec for detailed inforamtion
> 
> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  drivers/clocksource/arm_arch_timer.c |  129 ++++++++++++++++++++++++++++++----
>  include/clocksource/arm_arch_timer.h |    7 +-
>  2 files changed, 120 insertions(+), 16 deletions(-)
 
[...]

> +#ifdef CONFIG_ACPI
> +void __init arch_timer_acpi_init(void)
> +{
> +	struct acpi_table_gtdt *gtdt;
> +	acpi_size tbl_size;
> +	int trigger, polarity;
> +	void __iomem *base = NULL;
> +
> +	if (acpi_disabled)
> +		return;
> +
> +	if (arch_timers_present & ARCH_CP15_TIMER) {
> +		pr_warn("arch_timer: already initialized, skipping\n");
> +		return;
> +	}
> +
> +	if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_GTDT, 0,
> +			(struct acpi_table_header **)&gtdt, &tbl_size))) {
> +		pr_err("arch_timer: GTDT table not defined\n");
> +		return;
> +	}
> +
> +	arch_timers_present |= ARCH_CP15_TIMER;
> +
> +	/*
> +	 * Get the timer frequency. Since there is no frequency info
> +	 * in the GTDT table, so we should read it from CNTFREG register
> +	 * or hard code here to wait for the new ACPI spec available.
> +	 */

If the core's CNTFRQ register does not hold the correct value, that is a
horrendous firmware bug. The clock-frequency property in the DT is a
horrific workaround for buggy firmware.

We should not duplicate it in ACPI; people should be strongly encouraged
to fix their firmware to do what it is supposed to do.

Rely on CNTFRQ only. If it is wrong, then bail out. Let's not create a
fertile environment for buggy firmware.

> +	if (!gtdt->address) {
> +		arch_timer_rate = arch_timer_get_cntfrq();
> +	} else {
> +		base = ioremap(gtdt->address, CNTFRQ);
> +		if (!base) {
> +			pr_warn("arch_timer: unable to map arch timer base address\n");
> +			return;
> +		}
> +
> +		arch_timer_rate = readl_relaxed(base + CNTFRQ);
> +		iounmap(base);
> +	}
> +
> +	if (!arch_timer_rate) {
> +		/* Hard code here to set frequence ? */
> +		pr_warn("arch_timer: Could not get frequency from GTDT table or CNTFREG\n");
> +	}
> +
> +	if (gtdt->secure_pl1_interrupt) {
> +		trigger = (gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE) ?
> +			ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
> +		polarity =
> +			(gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
> +			? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> +		arch_timer_ppi[0] = acpi_register_gsi(NULL,
> +				gtdt->secure_pl1_interrupt, trigger, polarity);
> +	}

This pattern looks like it can be factored out. I don't see why the
driver needs to have such intimate knowledge of the interrrupt.

> +	if (gtdt->non_secure_pl1_interrupt) {
> +		trigger =
> +			(gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE)
> +			? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
> +		polarity =
> +		(gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
> +			? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> +		arch_timer_ppi[1] = acpi_register_gsi(NULL,
> +			gtdt->non_secure_pl1_interrupt, trigger, polarity);
> +	}
> +	if (gtdt->virtual_timer_interrupt) {
> +		trigger = (gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_MODE)
> +			? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
> +		polarity =
> +		(gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_POLARITY)
> +			? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> +		arch_timer_ppi[2] = acpi_register_gsi(NULL,
> +			gtdt->virtual_timer_interrupt, trigger, polarity);
> +	}
> +	if (gtdt->non_secure_pl2_interrupt) {
> +		trigger =
> +			(gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_MODE)
> +			? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
> +		polarity =
> +		(gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_POLARITY)
> +			? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> +		arch_timer_ppi[3] = acpi_register_gsi(NULL,
> +			gtdt->non_secure_pl2_interrupt, trigger, polarity);
> +	}

Please factor out the interrupt parsing.

Thanks,
Mark.

  reply	other threads:[~2013-12-03 17:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-03 16:41 [RFC part3 PATCH 0/2] Using " Hanjun Guo
2013-12-03 16:41 ` [RFC part3 PATCH 1/2] clocksource / arch_timer: Use " Hanjun Guo
2013-12-03 17:04   ` Mark Rutland [this message]
2013-12-04 14:25     ` Hanjun Guo
2013-12-05  3:43   ` Arnd Bergmann
2013-12-05 13:52     ` Hanjun Guo
2013-12-03 16:41 ` [RFC part3 PATCH 2/2] ARM64 / clocksource: Use arch_timer_acpi_init() Hanjun Guo
2013-12-03 17:08   ` Mark Rutland
2013-12-04 14:27     ` Hanjun Guo
2013-12-04 15:07       ` Mark Rutland
2013-12-05 13:09         ` Hanjun Guo
     [not found] <1386069328-22502-1-git-send-email-hanjun.guo@linaro.org>
     [not found] ` <1386069328-22502-2-git-send-email-hanjun.guo@linaro.org>
2013-12-04 15:33   ` [RFC part3 PATCH 1/2] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer Rob Herring
2013-12-05 13:26     ` Hanjun Guo

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=20131203170407.GA16025@e106331-lin.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=amit.daniel@samsung.com \
    --cc=bhelgaas@google.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=grant.likely@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=jonathan@jonmasters.org \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mjg59@srcf.ucam.org \
    --cc=olof@lixom.net \
    --cc=patches@linaro.org \
    --cc=rjw@rjwysocki.net \
    --cc=rob.herring@calxeda.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®