From: Hans de Goede <hdegoede@redhat.com>
To: Orlando Chamberlain <orlandoch.dev@gmail.com>,
platform-driver-x86@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Mark Gross" <markgross@kernel.org>,
"Jaroslav Kysela" <perex@perex.cz>,
"Takashi Iwai" <tiwai@suse.com>,
"Hawking Zhang" <Hawking.Zhang@amd.com>,
"Andrey Grodzovsky" <andrey.grodzovsky@amd.com>,
"Lijo Lazar" <lijo.lazar@amd.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>,
"Somalapuram Amaranath" <Amaranath.Somalapuram@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Bokun Zhang" <Bokun.Zhang@amd.com>,
"Jack Xiao" <Jack.Xiao@amd.com>,
"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
"Pierre-Louis Bossart" <pierre-louis.bossart@linux.intel.com>,
"Rander Wang" <rander.wang@intel.com>,
"Ranjani Sridharan" <ranjani.sridharan@linux.intel.com>,
"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
"Yong Zhi" <yong.zhi@intel.com>, "Evan Quan" <evan.quan@amd.com>,
"Kerem Karabay" <kekrby@gmail.com>,
"Aditya Garg" <gargaditya08@live.com>,
"Aun-Ali Zaidi" <admin@kodeit.net>
Subject: Re: [RFC PATCH 5/9] apple-gmux: Use GMSP acpi method for interrupt clear
Date: Fri, 10 Feb 2023 20:43:58 +0100 [thread overview]
Message-ID: <ee952253-9ee4-aa81-fefa-609cbf6e1e2b@redhat.com> (raw)
In-Reply-To: <20230210044826.9834-6-orlandoch.dev@gmail.com>
Hi,
On 2/10/23 05:48, Orlando Chamberlain wrote:
> This is needed for interrupts to be cleared correctly on MMIO based
> gmux's. It is untested if this helps/hinders other gmux types, but I
> have seen the GMSP method in the acpi tables of a MacBook with an
> indexed gmux.
>
> If this turns out to break support for older gmux's, this can instead
> be only done on MMIO gmux's.
>
> There is also a "GMLV" acpi method, and the "GMSP" method can be called
> with 1 as its argument, but the purposes of these aren't known and they
> don't seem to be needed.
>
> Signed-off-by: Orlando Chamberlain <orlandoch.dev@gmail.com>
> ---
> drivers/platform/x86/apple-gmux.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c
> index 760434a527c1..c605f036ea0b 100644
> --- a/drivers/platform/x86/apple-gmux.c
> +++ b/drivers/platform/x86/apple-gmux.c
> @@ -494,8 +494,29 @@ static const struct apple_gmux_config apple_gmux_index = {
> * MCP79, on all following generations it's GPIO pin 6 of the Intel PCH.
> * The GPE merely signals that an interrupt occurred, the actual type of event
> * is identified by reading a gmux register.
> + *
> + * On MMIO gmux's, we also need to call the acpi method GMSP to properly clear
> + * interrupts. TODO: Do other types need this? Does this break other types?
> */
>
> +static int gmux_call_acpi_gmsp(struct apple_gmux_data *gmux_data, int arg)
> +{
> + acpi_status status = AE_OK;
> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
> + struct acpi_object_list arg_list = { 1, &arg0 };
> +
> + arg0.integer.value = arg;
> +
> + status = acpi_evaluate_object(gmux_data->dhandle, "GMSP", &arg_list, NULL);
> + if (ACPI_FAILURE(status)) {
> + pr_err("GMSP call failed: %s\n",
> + acpi_format_exception(status));
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> static inline void gmux_disable_interrupts(struct apple_gmux_data *gmux_data)
> {
> gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_ENABLE,
> @@ -519,7 +540,10 @@ static void gmux_clear_interrupts(struct apple_gmux_data *gmux_data)
>
> /* to clear interrupts write back current status */
> status = gmux_interrupt_get_status(gmux_data);
> - gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_STATUS, status);
> + if (status) {
> + gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_STATUS, status);
> + gmux_call_acpi_gmsp(gmux_data, 0);
Ugh no, please don't go around calling random ACPI methods from untested
firmware revisions / device models.
ACPI code (even Apple's I have learned) tends to be full of bugs. If we
did not need to call GMSP before then please lets keep not calling it
on the older models. Just because it is there does not mean that calling
it is useful, it might even be harmful.
Regards,
Hans
> + }
> }
>
> static void gmux_notify_handler(acpi_handle device, u32 value, void *context)
next prev parent reply other threads:[~2023-02-10 19:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 4:48 [RFC PATCH 0/9] apple-gmux: support MMIO gmux type on T2 Macs Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 1/9] apple-gmux: use cpu_to_be32 instead of manual reorder Orlando Chamberlain
2023-02-10 19:09 ` Hans de Goede
2023-02-10 19:19 ` Hans de Goede
2023-02-10 23:30 ` Orlando Chamberlain
2023-02-11 11:27 ` Hans de Goede
2023-02-10 19:33 ` Hans de Goede
2023-02-10 22:52 ` David Laight
2023-02-10 4:48 ` [RFC PATCH 2/9] apple-gmux: consolidate version reading Orlando Chamberlain
2023-02-10 19:41 ` Hans de Goede
2023-02-10 23:36 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 3/9] apple-gmux: use first bit to check switch state Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 4/9] apple-gmux: refactor gmux types Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 5/9] apple-gmux: Use GMSP acpi method for interrupt clear Orlando Chamberlain
2023-02-10 19:43 ` Hans de Goede [this message]
2023-02-10 23:40 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 6/9] apple-gmux: support MMIO gmux on T2 Macs Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 7/9] apple-gmux: add sysfs interface Orlando Chamberlain
2023-02-10 20:15 ` Hans de Goede
2023-02-10 20:23 ` Hans de Goede
2023-02-10 23:44 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 8/9] hda/hdmi: Register with vga_switcheroo on Dual GPU Macbooks Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 9/9] drm/amdgpu: register a vga_switcheroo client for all GPUs that are not thunderbolt attached Orlando Chamberlain
2023-02-10 15:53 ` Alex Deucher
2023-02-10 16:07 ` Hans de Goede
2023-02-10 16:37 ` Alex Deucher
2023-02-10 23:54 ` Orlando Chamberlain
2023-02-10 16:30 ` [RFC PATCH 0/9] apple-gmux: support MMIO gmux type on T2 Macs Alex Deucher
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=ee952253-9ee4-aa81-fefa-609cbf6e1e2b@redhat.com \
--to=hdegoede@redhat.com \
--cc=Amaranath.Somalapuram@amd.com \
--cc=Bokun.Zhang@amd.com \
--cc=Hawking.Zhang@amd.com \
--cc=Jack.Xiao@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=YiPeng.Chai@amd.com \
--cc=admin@kodeit.net \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrey.grodzovsky@amd.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=evan.quan@amd.com \
--cc=gargaditya08@live.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=kekrby@gmail.com \
--cc=lijo.lazar@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=markgross@kernel.org \
--cc=orlandoch.dev@gmail.com \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rander.wang@intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=tiwai@suse.com \
--cc=yong.zhi@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
all inboxes | Powered by JetHome®