linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mateusz Majewski <m.majewski2@samsung.com>
To: linux.amoon@gmail.com
Cc: alim.akhtar@samsung.com, bzolnier@gmail.com,
	daniel.lezcano@linaro.org, krzk@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-samsung-soc@vger.kernel.org, lukasz.luba@arm.com,
	rafael@kernel.org, rui.zhang@intel.com,
	Mateusz Majewski <m.majewski2@samsung.com>
Subject: Re: [RRC v1 2/3] thermal/drivers/exynos: Handle temperature threshold interrupts and clear corresponding IRQs
Date: Wed, 18 Jun 2025 13:52:11 +0200	[thread overview]
Message-ID: <20250618115211.2239335-1-m.majewski2@samsung.com> (raw)
In-Reply-To: <20250616163831.8138-3-linux.amoon@gmail.com>

Hello :)

> +#define INTSTAT_FALL2	BIT(24)
> +#define INTSTAT_FALL1	BIT(20)
> +#define INTSTAT_FALL0	BIT(16)
> +#define INTSTAT_RISE2	BIT(8)
> +#define INTSTAT_RISE1	BIT(4)
> +#define INTSTAT_RISE0	BIT(0)
> +
> +#define INTCLEAR_FALL2	BIT(24)
> +#define INTCLEAR_FALL1	BIT(20)
> +#define INTCLEAR_FALL0	BIT(16)
> +#define INTCLEAR_RISE2	BIT(8)
> +#define INTCLEAR_RISE1	BIT(4)
> +#define INTCLEAR_RISE0	BIT(0)

> +	/* Map INTSTAT bits to INTCLEAR bits */
> +	if (val_irq & INTSTAT_FALL2)
> +		clearirq |= INTCLEAR_FALL2;
> +	else if (val_irq & INTSTAT_FALL1)
> +		clearirq |= INTCLEAR_FALL1;
> +	else if (val_irq & INTSTAT_FALL0)
> +		clearirq |= INTCLEAR_FALL0;
> +	else if (val_irq & INTSTAT_RISE2)
> +		clearirq |= INTCLEAR_RISE2;
> +	else if (val_irq & INTSTAT_RISE1)
> +		clearirq |= INTCLEAR_RISE1;
> +	else if (val_irq & INTSTAT_RISE0)
> +		clearirq |= INTCLEAR_RISE0;

This implies that only these 6 bits are used. Is this true for all SoCs
supported by this driver? My understanding is that Exynos 5433 in particular
uses bits 7:0 for rise interrupts and 23:16 for fall interrupts. When I tested
this patch (both alone and the whole series) on 5433 by running some CPU load,
the interrupt seemed to not fire consistently:
/sys/class/thermal/cooling_device1/cur_state would never go above 1 (which is
consistent with the interrupt firing once, not getting cleared and never firing
again; without this patch, it consistently went up to 6) and I got a quick
reboot every time.

Thank you,
Mateusz Majewski

  parent reply	other threads:[~2025-06-18 11:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-16 16:38 [RRC v1 0/3] Simplify Exynos TMU IRQ clean logic Anand Moon
2025-06-16 16:38 ` [RRC v1 1/3] thermal/drivers/exynos: Remove unused base_second mapping and references Anand Moon
     [not found]   ` <CGME20250618125812eucas1p11a1ab5210d4efa95a51b3bc7c4f0924d@eucas1p1.samsung.com>
2025-06-18 12:58     ` Mateusz Majewski
2025-06-19  5:45       ` Anand Moon
2025-06-21  7:17         ` Anand Moon
     [not found]           ` <CGME20250625143825eucas1p2e95ba80552cd289b6e05db33f32ec14a@eucas1p2.samsung.com>
2025-06-25 14:38             ` Mateusz Majewski
2025-06-26 18:22               ` Anand Moon
2025-06-16 16:38 ` [RRC v1 2/3] thermal/drivers/exynos: Handle temperature threshold interrupts and clear corresponding IRQs Anand Moon
     [not found]   ` <CGME20250618115220eucas1p2b9d37e8cdd1997fa010f51cecdea5e4f@eucas1p2.samsung.com>
2025-06-18 11:52     ` Mateusz Majewski [this message]
2025-06-19  5:45       ` Anand Moon
2025-06-21  7:16         ` Anand Moon
     [not found]           ` <CGME20250624075847eucas1p2db6e908f78aa603bdf6aec38b653e9af@eucas1p2.samsung.com>
2025-06-24  7:58             ` Mateusz Majewski
2025-06-26 18:21               ` Anand Moon
2025-06-16 16:38 ` [RRC v1 3/3] thermal/drivers/exynos: Refactor IRQ clear logic using SoC-specific config Anand Moon

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=20250618115211.2239335-1-m.majewski2@samsung.com \
    --to=m.majewski2@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=bzolnier@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux.amoon@gmail.com \
    --cc=lukasz.luba@arm.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.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;
as well as URLs for NNTP newsgroup(s).