kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/drivers/mailbox/pcc.c

944 lines
25 KiB
Raw Permalink Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-27 08:55:06 +02:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
Mailbox: Restructure and simplify PCC mailbox code Previously the PCC driver depended on the client side to map the communication space base address. This region was was then used in the PCC driver and the client side. The client side used this region to read and write its data and the PCC driver used it to only write the PCC command. Removing this split simplifies the PCC driver a lot. This patch moves all communication region read/writes to the client side. The PCC clients can now drive the PCC mailbox controller via the mbox_client_txdone() method. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
2015-01-27 16:03:57 -05:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
Mailbox: Restructure and simplify PCC mailbox code Previously the PCC driver depended on the client side to map the communication space base address. This region was was then used in the PCC driver and the client side. The client side used this region to read and write its data and the PCC driver used it to only write the PCC command. Removing this split simplifies the PCC driver a lot. This patch moves all communication region read/writes to the client side. The PCC clients can now drive the PCC mailbox controller via the mbox_client_txdone() method. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
2015-01-27 16:03:57 -05:00
mailbox: fix various typos in comments Fix trivial typos in mailbox driver comments. s/Intergrated/Integrated/ s/extenstion/extension/ s/atleast/at least/ s/commnunication/communication/ s/assgined/assigned/ s/commnunication/communication/ s/recevied/received/ s/succeded/succeeded/ s/implmentation/implementation/ s/definiation/definition/ s/traget/target/ s/wont/won't/ Cc: trivial@kernel.org Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-03-12 19:31:10 -07:00
Mailbox: Restructure and simplify PCC mailbox code Previously the PCC driver depended on the client side to map the communication space base address. This region was was then used in the PCC driver and the client side. The client side used this region to read and write its data and the PCC driver used it to only write the PCC command. Removing this split simplifies the PCC driver a lot. This patch moves all communication region read/writes to the client side. The PCC clients can now drive the PCC mailbox controller via the mbox_client_txdone() method. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
2015-01-27 16:03:57 -05:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Add PCC register bundle and associated accessor functions Extended PCC subspaces introduces more registers into the PCCT. In order to consolidate access to these registers and to keep all the details contained in one place, let us introduce PCC register bundle that holds the ACPI Generic Address Structure as well as the virtual address for the same if it is mapped in the OS. It also contains the various masks used to access the register and the associated read, write and read-modify-write accessors. We can also clean up the initialisations by having a helper function for the same. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:52 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: optimized pcc_send_data pcc_send_data() can be invoked during the execution of performance critical code as in cppc_cpufreq driver. With acpi_* APIs, the doorbell register accessed in pcc_send_data() if present in system memory will be searched (in cached virt to phys addr mapping), mapped, read/written and then unmapped. These operations take significant amount of time. This patch maps the performance critical doorbell register during init and then reads/writes to it directly using the mapped virtual address. This patch + similar changes to CPPC acpi driver reduce the time per freq. transition from around 200us to about 20us for the CPPC cpufreq driver Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Acked-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-17 13:21:01 -07:00
mailbox: PCC: Fix lockdep warning when request PCC channel This patch fixes the lockdep warning below DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at linux-next/kernel/locking/lockdep.c:2876 lockdep_trace_alloc+0xe0/0xf0 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-11756-g86c5152 #46 ... Call trace: Exception stack(0xffff8007da837890 to 0xffff8007da8379c0) 7880: ffff8007da834000 0001000000000000 78a0: ffff8007da837a70 ffff0000081111a0 00000000600000c5 000000000000003d 78c0: 9374bc6a7f3c7832 0000000000381878 ffff000009db7ab8 000000000000002f 78e0: ffff00000811aabc ffff000008be2548 ffff8007da837990 ffff00000811adf8 7900: ffff8007da834000 00000000024080c0 00000000000000c0 ffff000009021000 7920: 0000000000000000 0000000000000000 ffff000008c8f7c8 ffff8007da579810 7940: 000000000000002f ffff8007da858000 0000000000000000 0000000000000001 7960: 0000000000000001 0000000000000000 ffff00000811a468 0000000000000002 7980: 656c62617369645f 0000000000038187 00000000000000ee ffff8007da837850 79a0: ffff000009db50c0 ffff000009db569d 0000000000000006 ffff000089db568f [<ffff0000081111a0>] lockdep_trace_alloc+0xe0/0xf0 [<ffff0000081f4950>] __kmalloc_track_caller+0x50/0x250 [<ffff00000857c088>] devres_alloc_node+0x28/0x60 [<ffff0000081220e0>] devm_request_threaded_irq+0x50/0xe0 [<ffff0000087e6220>] pcc_mbox_request_channel+0x110/0x170 [<ffff0000084b2660>] acpi_cppc_processor_probe+0x264/0x414 [<ffff0000084ae9f4>] __acpi_processor_start+0x28/0xa0 [<ffff0000084aeab0>] acpi_processor_start+0x44/0x54 [<ffff00000857897c>] driver_probe_device+0x1fc/0x2b0 [<ffff000008578ae4>] __driver_attach+0xb4/0xc0 [<ffff00000857683c>] bus_for_each_dev+0x5c/0xa0 [<ffff000008578110>] driver_attach+0x20/0x30 [<ffff000008577c20>] bus_add_driver+0x110/0x230 [<ffff000008579320>] driver_register+0x60/0x100 [<ffff000008d478b8>] acpi_processor_driver_init+0x2c/0xb0 [<ffff000008083168>] do_one_initcall+0x38/0x130 [<ffff000008d20d6c>] kernel_init_freeable+0x210/0x2b4 [<ffff000008945d90>] kernel_init+0x10/0x110 [<ffff000008082e80>] ret_from_fork+0x10/0x50 It's because the spinlock inside pcc_mbox_request_channel() is kept too long. This patch releases spinlock before request_irq() and free_irq() to fix this issue as spinlock is only needed to protect the channel data. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-11-14 11:19:02 -08:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Add PCC register bundle and associated accessor functions Extended PCC subspaces introduces more registers into the PCCT. In order to consolidate access to these registers and to keep all the details contained in one place, let us introduce PCC register bundle that holds the ACPI Generic Address Structure as well as the virtual address for the same if it is mapped in the OS. It also contains the various masks used to access the register and the associated read, write and read-modify-write accessors. We can also clean up the initialisations by having a helper function for the same. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:52 +01:00
mailbox: pcc: Refactor all PCC channel information into a structure Currently all the PCC channel specific information are stored/maintained in global individual arrays for each of those information. It is not scalable and not clean if we have to stash more channel specific information. Couple of reasons to stash more information are to extend the support to Type 3/4 PCCT subspace and also to avoid accessing the PCCT table entries themselves each time we need the information. This patch moves all those PCC channel specific information into a separate structure pcc_chan_info. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:46 +01:00
mailbox: pcc: Add pcc_mbox_chan structure to hold shared memory region info Currently PCC mailbox controller sets con_priv in each channel to hold the pointer to pcct subspace entry it corresponds to. The mailbox user will then fetch this pointer from the channel descriptor they get when they request for the channel. Using that pointer they then parse the pcct entry again to fetch all the information about shared memory region. In order to remove individual users of PCC mailbox parsing the PCCT subspace entries to fetch same information, let us consolidate the same in pcc mailbox controller by parsing all the shared memory region information into a structure that can also hold the mbox_chan pointer it represent. This can then be used as main PCC mailbox channel pointer that we can return as part of pcc_mbox_request_channel instead of standard mailbox channel pointer. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:49 +01:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Rename doorbell ack to platform interrupt ack register The specification refers this register and associated bitmask as platform interrupt acknowledge register. Let us rename it so that it is easier to map and understand. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:51 +01:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Fix command timeout due to missed interrupt PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:28 +01:00
mailbox: pcc: Refactor all PCC channel information into a structure Currently all the PCC channel specific information are stored/maintained in global individual arrays for each of those information. It is not scalable and not clean if we have to stash more channel specific information. Couple of reasons to stash more information are to extend the support to Type 3/4 PCCT subspace and also to avoid accessing the PCCT table entries themselves each time we need the information. This patch moves all those PCC channel specific information into a separate structure pcc_chan_info. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:46 +01:00
mailbox: pcc: Add pcc_mbox_chan structure to hold shared memory region info Currently PCC mailbox controller sets con_priv in each channel to hold the pointer to pcct subspace entry it corresponds to. The mailbox user will then fetch this pointer from the channel descriptor they get when they request for the channel. Using that pointer they then parse the pcct entry again to fetch all the information about shared memory region. In order to remove individual users of PCC mailbox parsing the PCCT subspace entries to fetch same information, let us consolidate the same in pcc mailbox controller by parsing all the shared memory region information into a structure that can also hold the mbox_chan pointer it represent. This can then be used as main PCC mailbox channel pointer that we can return as part of pcc_mbox_request_channel instead of standard mailbox channel pointer. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:49 +01:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Rename doorbell ack to platform interrupt ack register The specification refers this register and associated bitmask as platform interrupt acknowledge register. Let us rename it so that it is easier to map and understand. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:51 +01:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Refactor all PCC channel information into a structure Currently all the PCC channel specific information are stored/maintained in global individual arrays for each of those information. It is not scalable and not clean if we have to stash more channel specific information. Couple of reasons to stash more information are to extend the support to Type 3/4 PCCT subspace and also to avoid accessing the PCCT table entries themselves each time we need the information. This patch moves all those PCC channel specific information into a separate structure pcc_chan_info. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:46 +01:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Refactor all PCC channel information into a structure Currently all the PCC channel specific information are stored/maintained in global individual arrays for each of those information. It is not scalable and not clean if we have to stash more channel specific information. Couple of reasons to stash more information are to extend the support to Type 3/4 PCCT subspace and also to avoid accessing the PCCT table entries themselves each time we need the information. This patch moves all those PCC channel specific information into a separate structure pcc_chan_info. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:46 +01:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: optimized pcc_send_data pcc_send_data() can be invoked during the execution of performance critical code as in cppc_cpufreq driver. With acpi_* APIs, the doorbell register accessed in pcc_send_data() if present in system memory will be searched (in cached virt to phys addr mapping), mapped, read/written and then unmapped. These operations take significant amount of time. This patch maps the performance critical doorbell register during init and then reads/writes to it directly using the mapped virtual address. This patch + similar changes to CPPC acpi driver reduce the time per freq. transition from around 200us to about 20us for the CPPC cpufreq driver Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Acked-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-17 13:21:01 -07:00
mailbox: pcc: Drop handling invalid bit-width in {read,write}_register pcc_chan_reg_init now checks if the register bit width is within the list [8, 16, 32, 64] and flags error if that is not the case. Therefore there is no need to handling invalid bit-width in both read_register and write_register. We can drop that along with the return values for these 2 functions. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:54 +01:00
mailbox: pcc: optimized pcc_send_data pcc_send_data() can be invoked during the execution of performance critical code as in cppc_cpufreq driver. With acpi_* APIs, the doorbell register accessed in pcc_send_data() if present in system memory will be searched (in cached virt to phys addr mapping), mapped, read/written and then unmapped. These operations take significant amount of time. This patch maps the performance critical doorbell register during init and then reads/writes to it directly using the mapped virtual address. This patch + similar changes to CPPC acpi driver reduce the time per freq. transition from around 200us to about 20us for the CPPC cpufreq driver Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Acked-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-17 13:21:01 -07:00
mailbox: pcc: Drop handling invalid bit-width in {read,write}_register pcc_chan_reg_init now checks if the register bit width is within the list [8, 16, 32, 64] and flags error if that is not the case. Therefore there is no need to handling invalid bit-width in both read_register and write_register. We can drop that along with the return values for these 2 functions. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:54 +01:00
mailbox: pcc: optimized pcc_send_data pcc_send_data() can be invoked during the execution of performance critical code as in cppc_cpufreq driver. With acpi_* APIs, the doorbell register accessed in pcc_send_data() if present in system memory will be searched (in cached virt to phys addr mapping), mapped, read/written and then unmapped. These operations take significant amount of time. This patch maps the performance critical doorbell register during init and then reads/writes to it directly using the mapped virtual address. This patch + similar changes to CPPC acpi driver reduce the time per freq. transition from around 200us to about 20us for the CPPC cpufreq driver Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Acked-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-17 13:21:01 -07:00
mailbox: pcc: Add PCC register bundle and associated accessor functions Extended PCC subspaces introduces more registers into the PCCT. In order to consolidate access to these registers and to keep all the details contained in one place, let us introduce PCC register bundle that holds the ACPI Generic Address Structure as well as the virtual address for the same if it is mapped in the OS. It also contains the various masks used to access the register and the associated read, write and read-modify-write accessors. We can also clean up the initialisations by having a helper function for the same. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:52 +01:00
mailbox: pcc: Drop handling invalid bit-width in {read,write}_register pcc_chan_reg_init now checks if the register bit width is within the list [8, 16, 32, 64] and flags error if that is not the case. Therefore there is no need to handling invalid bit-width in both read_register and write_register. We can drop that along with the return values for these 2 functions. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:54 +01:00
mailbox: pcc: Add PCC register bundle and associated accessor functions Extended PCC subspaces introduces more registers into the PCCT. In order to consolidate access to these registers and to keep all the details contained in one place, let us introduce PCC register bundle that holds the ACPI Generic Address Structure as well as the virtual address for the same if it is mapped in the OS. It also contains the various masks used to access the register and the associated read, write and read-modify-write accessors. We can also clean up the initialisations by having a helper function for the same. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:52 +01:00
mailbox: pcc: Drop handling invalid bit-width in {read,write}_register pcc_chan_reg_init now checks if the register bit width is within the list [8, 16, 32, 64] and flags error if that is not the case. Therefore there is no need to handling invalid bit-width in both read_register and write_register. We can drop that along with the return values for these 2 functions. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:54 +01:00
mailbox: pcc: Add PCC register bundle and associated accessor functions Extended PCC subspaces introduces more registers into the PCCT. In order to consolidate access to these registers and to keep all the details contained in one place, let us introduce PCC register bundle that holds the ACPI Generic Address Structure as well as the virtual address for the same if it is mapped in the OS. It also contains the various masks used to access the register and the associated read, write and read-modify-write accessors. We can also clean up the initialisations by having a helper function for the same. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:52 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Return early if no GAS register from pcc_mbox_cmd_complete_check pcc_mbox_cmd_complete_check() accesses pchan->cmd_complete.gas to check command completion status. Even if GAS is NULL, pcc_chan_reg_read() gets called which returns success doing nothing and then we return. Add an early return if pchan->cmd_complete.gas == NULL before performing any operations. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:50 +00:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Refactor error handling in irq handler into separate function The existing error handling logic in pcc_mbox_irq() is intermixed with the main flow of the function. The command complete check and the complete complete update/acknowledgment are nicely factored into separate functions. Moves error detection and clearing logic into a separate function called: pcc_mbox_error_check_and_clear() by extracting error-handling logic from pcc_mbox_irq(). This ensures error checking and clearing are handled separately and it improves maintainability by keeping the IRQ handler focused on processing events. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:52 +00:00
mailbox: pcc: don't zero error register The error status mask for a type 3/4 subspace is used for reading the error status, and the bitwise inverse is used for clearing the error with the intent being to preserve any of the non-error bits. However, we were previously applying the mask to extract the status and then applying the inverse to the result which ended up clearing all bits. Instead, store the inverse mask in the preserve mask and then use that on the original value read from the error status so that only the error is cleared. Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Signed-off-by: Jamie Iles <jamie.iles@oss.qualcomm.com> Signed-off-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-11-05 14:42:29 +00:00
mailbox: pcc: Refactor error handling in irq handler into separate function The existing error handling logic in pcc_mbox_irq() is intermixed with the main flow of the function. The command complete check and the complete complete update/acknowledgment are nicely factored into separate functions. Moves error detection and clearing logic into a separate function called: pcc_mbox_error_check_and_clear() by extracting error-handling logic from pcc_mbox_irq(). This ensures error checking and clearing are handled separately and it improves maintainability by keeping the IRQ handler focused on processing events. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:52 +00:00
mailbox: pcc: Refactor and simplify check_and_ack() The existing check_and_ack() function had unnecessary complexity. The logic could be streamlined to improve code readability and maintainability. The command update register needs to be updated in order to acknowledge the platform notification through type 4 channel. So it can be done unconditionally. Currently it is complicated just to make use of pcc_send_data() which also executes the same updation. In order to simplify, let us just ring the doorbell directly from check_and_ack() instead of calling into pcc_send_data(). While at it, rename it into pcc_chan_check_and_ack() to maintain consistency in the driver. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:54 +00:00
mailbox: pcc: Check before sending MCTP PCC response ACK Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-20 14:02:14 -05:00
mailbox: pcc: Refactor and simplify check_and_ack() The existing check_and_ack() function had unnecessary complexity. The logic could be streamlined to improve code readability and maintainability. The command update register needs to be updated in order to acknowledge the platform notification through type 4 channel. So it can be done unconditionally. Currently it is complicated just to make use of pcc_send_data() which also executes the same updation. In order to simplify, let us just ring the doorbell directly from check_and_ack() instead of calling into pcc_send_data(). While at it, rename it into pcc_chan_check_and_ack() to maintain consistency in the driver. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:54 +00:00
mailbox: pcc: Check before sending MCTP PCC response ACK Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-20 14:02:14 -05:00
mailbox: pcc: Refactor and simplify check_and_ack() The existing check_and_ack() function had unnecessary complexity. The logic could be streamlined to improve code readability and maintainability. The command update register needs to be updated in order to acknowledge the platform notification through type 4 channel. So it can be done unconditionally. Currently it is complicated just to make use of pcc_send_data() which also executes the same updation. In order to simplify, let us just ring the doorbell directly from check_and_ack() instead of calling into pcc_send_data(). While at it, rename it into pcc_chan_check_and_ack() to maintain consistency in the driver. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:54 +00:00
mailbox: pcc: Check before sending MCTP PCC response ACK Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-20 14:02:14 -05:00
mailbox: pcc: Refactor and simplify check_and_ack() The existing check_and_ack() function had unnecessary complexity. The logic could be streamlined to improve code readability and maintainability. The command update register needs to be updated in order to acknowledge the platform notification through type 4 channel. So it can be done unconditionally. Currently it is complicated just to make use of pcc_send_data() which also executes the same updation. In order to simplify, let us just ring the doorbell directly from check_and_ack() instead of calling into pcc_send_data(). While at it, rename it into pcc_chan_check_and_ack() to maintain consistency in the driver. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:54 +00:00
mailbox: pcc: Check before sending MCTP PCC response ACK Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-20 14:02:14 -05:00
mailbox: pcc: Refactor and simplify check_and_ack() The existing check_and_ack() function had unnecessary complexity. The logic could be streamlined to improve code readability and maintainability. The command update register needs to be updated in order to acknowledge the platform notification through type 4 channel. So it can be done unconditionally. Currently it is complicated just to make use of pcc_send_data() which also executes the same updation. In order to simplify, let us just ring the doorbell directly from check_and_ack() instead of calling into pcc_send_data(). While at it, rename it into pcc_chan_check_and_ack() to maintain consistency in the driver. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:54 +00:00
mailbox: pcc: Check before sending MCTP PCC response ACK Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-20 14:02:14 -05:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Fix kernel doc warnings Kernel doc validation script is unhappy and complains with the below set of warnings. | drivers/mailbox/pcc.c:179: warning: Function parameter or member 'irq' | not described in 'pcc_mbox_irq' | drivers/mailbox/pcc.c:179: warning: Function parameter or member 'p' | not described in 'pcc_mbox_irq' | drivers/mailbox/pcc.c:378: warning: expecting prototype for | parse_pcc_subspaces(). Prototype was for parse_pcc_subspace() instead Fix it. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:44 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Refactor all PCC channel information into a structure Currently all the PCC channel specific information are stored/maintained in global individual arrays for each of those information. It is not scalable and not clean if we have to stash more channel specific information. Couple of reasons to stash more information are to extend the support to Type 3/4 PCCT subspace and also to avoid accessing the PCCT table entries themselves each time we need the information. This patch moves all those PCC channel specific information into a separate structure pcc_chan_info. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:46 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Always clear the platform ack interrupt first The PCC mailbox interrupt handler (pcc_mbox_irq()) currently checks for command completion flags and any error status before clearing the interrupt. The below sequence highlights an issue in the handling of PCC mailbox interrupts, specifically when dealing with doorbell notifications and acknowledgment between the OSPM and the platform where type3 and type4 channels are sharing the interrupt. ------------------------------------------------------------------------- | T | Platform Firmware | OSPM/Linux PCC driver | |---|---------------------------------|---------------------------------| | 1 | | Build message in shmem | | 2 | | Ring Type3 chan doorbell | | 3 | Receives the doorbell interrupt | | | 4 | Process the message from OSPM | | | 5 | Build response for the message | | | 6 | Ring Platform ACK interrupt on | | | | Type3 chan to OSPM | Received the interrupt | | 7 | Build Notification in Type4 Chan| | | 8 | | Start processing interrupt in | | | | pcc_mbox_irq() handler | | 9 | | Enter PCC handler for Type4 chan| |10 | | Check command complete cleared | |11 | | Read the notification | |12 | | Clear Platform ACK interrupt | | | No effect from the previous step yet as the Platform ACK | | | interrupt has not yet been triggered for this channel | |13 | Ring Platform ACK interrupt on | | | | Type4 chan to OSPM | | |14 | | Enter PCC handler for Type3 chan| |15 | | Command complete is set. | |16 | | Read the response. | |17 | | Clear Platform ACK interrupt | |18 | | Leave PCC handler for Type3 | |19 | | Leave pcc_mbox_irq() handler | |20 | | Re-enter pcc_mbox_irq() handler | |21 | | Enter PCC handler for Type4 chan| |22 | | Leave PCC handler for Type4 chan| |23 | | Enter PCC handler for Type3 chan| |24 | | Leave PCC handler for Type3 chan| |25 | | Leave pcc_mbox_irq() handler | ------------------------------------------------------------------------- The key issue occurs when OSPM tries to acknowledge platform ack interrupt for a notification which is ready to be read and processed but the interrupt itself is not yet triggered by the platform. This ineffective acknowledgment leads to an issue later in time where the interrupt remains pending as we exit the interrupt handler without clearing the platform ack interrupt as there is no pending response or notification. The interrupt acknowledgment order is incorrect. To resolve this issue, the platform acknowledgment interrupt should always be cleared before processing the interrupt for any notifications or response. Reported-by: Robbie King <robbiek@xsightlabs.com> Reviewed-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Tested-by: Robbie King <robbiek@xsightlabs.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:48 +00:00
mailbox: pcc: Fix command timeout due to missed interrupt PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:28 +01:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Fix command timeout due to missed interrupt PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:28 +01:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Refactor error handling in irq handler into separate function The existing error handling logic in pcc_mbox_irq() is intermixed with the main flow of the function. The command complete check and the complete complete update/acknowledgment are nicely factored into separate functions. Moves error detection and clearing logic into a separate function called: pcc_mbox_error_check_and_clear() by extracting error-handling logic from pcc_mbox_irq(). This ensures error checking and clearing are handled separately and it improves maintainability by keeping the IRQ handler focused on processing events. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:52 +00:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Fix the possible race in updation of chan_in_use flag The function mbox_chan_received_data() calls the Rx callback of the mailbox client driver. The callback might set chan_in_use flag from pcc_send_data(). This flag's status determines whether the PCC channel is in use. However, there is a potential race condition where chan_in_use is updated incorrectly due to concurrency between the interrupt handler (pcc_mbox_irq()) and the command sender(pcc_send_data()). The 'chan_in_use' flag of a channel is set to true after sending a command. And the flag of the new command may be cleared erroneous by the interrupt handler afer mbox_chan_received_data() returns, As a result, the interrupt being level triggered can't be cleared in pcc_mbox_irq() and it will be disabled after the number of handled times exceeds the specified value. The error log is as follows: | kunpeng_hccs HISI04B2:00: PCC command executed timeout! | kunpeng_hccs HISI04B2:00: get port link status info failed, ret = -110 | irq 13: nobody cared (try booting with the "irqpoll" option) | Call trace: | dump_backtrace+0x0/0x210 | show_stack+0x1c/0x2c | dump_stack+0xec/0x130 | __report_bad_irq+0x50/0x190 | note_interrupt+0x1e4/0x260 | handle_irq_event+0x144/0x17c | handle_fasteoi_irq+0xd0/0x240 | __handle_domain_irq+0x80/0xf0 | gic_handle_irq+0x74/0x2d0 | el1_irq+0xbc/0x140 | mnt_clone_write+0x0/0x70 | file_update_time+0xcc/0x160 | fault_dirty_shared_page+0xe8/0x150 | do_shared_fault+0x80/0x1d0 | do_fault+0x118/0x1a4 | handle_pte_fault+0x154/0x230 | __handle_mm_fault+0x1ac/0x390 | handle_mm_fault+0xf0/0x250 | do_page_fault+0x184/0x454 | do_translation_fault+0xac/0xd4 | do_mem_abort+0x44/0xb4 | el0_da+0x40/0x74 | el0_sync_handler+0x60/0xb4 | el0_sync+0x168/0x180 | handlers: | pcc_mbox_irq | Disabling IRQ #13 To solve this issue, pcc_mbox_irq() must clear 'chan_in_use' flag before the call to mbox_chan_received_data(). Tested-by: Adam Young <admiyo@os.amperecomputing.com> Tested-by: Robbie King <robbiek@xsightlabs.com> Signed-off-by: Huisong Li <lihuisong@huawei.com> (sudeep.holla: Minor updates to the subject, commit message and comment) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:47 +00:00
mailbox: pcc: Fix command timeout due to missed interrupt PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:28 +01:00
mailbox: pcc: Fix the possible race in updation of chan_in_use flag The function mbox_chan_received_data() calls the Rx callback of the mailbox client driver. The callback might set chan_in_use flag from pcc_send_data(). This flag's status determines whether the PCC channel is in use. However, there is a potential race condition where chan_in_use is updated incorrectly due to concurrency between the interrupt handler (pcc_mbox_irq()) and the command sender(pcc_send_data()). The 'chan_in_use' flag of a channel is set to true after sending a command. And the flag of the new command may be cleared erroneous by the interrupt handler afer mbox_chan_received_data() returns, As a result, the interrupt being level triggered can't be cleared in pcc_mbox_irq() and it will be disabled after the number of handled times exceeds the specified value. The error log is as follows: | kunpeng_hccs HISI04B2:00: PCC command executed timeout! | kunpeng_hccs HISI04B2:00: get port link status info failed, ret = -110 | irq 13: nobody cared (try booting with the "irqpoll" option) | Call trace: | dump_backtrace+0x0/0x210 | show_stack+0x1c/0x2c | dump_stack+0xec/0x130 | __report_bad_irq+0x50/0x190 | note_interrupt+0x1e4/0x260 | handle_irq_event+0x144/0x17c | handle_fasteoi_irq+0xd0/0x240 | __handle_domain_irq+0x80/0xf0 | gic_handle_irq+0x74/0x2d0 | el1_irq+0xbc/0x140 | mnt_clone_write+0x0/0x70 | file_update_time+0xcc/0x160 | fault_dirty_shared_page+0xe8/0x150 | do_shared_fault+0x80/0x1d0 | do_fault+0x118/0x1a4 | handle_pte_fault+0x154/0x230 | __handle_mm_fault+0x1ac/0x390 | handle_mm_fault+0xf0/0x250 | do_page_fault+0x184/0x454 | do_translation_fault+0xac/0xd4 | do_mem_abort+0x44/0xb4 | el0_da+0x40/0x74 | el0_sync_handler+0x60/0xb4 | el0_sync+0x168/0x180 | handlers: | pcc_mbox_irq | Disabling IRQ #13 To solve this issue, pcc_mbox_irq() must clear 'chan_in_use' flag before the call to mbox_chan_received_data(). Tested-by: Adam Young <admiyo@os.amperecomputing.com> Tested-by: Robbie King <robbiek@xsightlabs.com> Signed-off-by: Huisong Li <lihuisong@huawei.com> (sudeep.holla: Minor updates to the subject, commit message and comment) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:47 +00:00
mailbox: pcc: Fix command timeout due to missed interrupt PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:28 +01:00
Revert "mailbox/pcc: support mailbox management of the shared buffer" This reverts commit 5378bdf6a611a32500fccf13d14156f219bb0c85. Commit 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") attempted to introduce generic helpers for managing the PCC shared memory, but it largely duplicates functionality already provided by the mailbox core and leaves gaps: 1. TX preparation: The mailbox framework already supports this via ->tx_prepare callback for mailbox clients. The patch adds pcc_write_to_buffer() and expects clients to toggle pchan->chan.manage_writes, but no drivers set manage_writes, so pcc_write_to_buffer() has no users. 2. RX handling: Data reception is already delivered through mbox_chan_received_data() and client ->rx_callback. The patch adds an optional pchan->chan.rx_alloc, which again has no users and duplicates the existing path. 3. Completion handling: While adding last_tx_done is directionally useful, the implementation only covers Type 3/4 and fails to handle the absence of a command_complete register, so it is incomplete for other types. Given the duplication and incomplete coverage, revert this change. Any new requirements should be addressed in focused follow-ups rather than bundling multiple behavioral changes together. Fixes: 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:15 +01:00
mailbox: pcc: Mark Tx as complete in PCC IRQ handler The PCC IRQ handler clears channel-in-use and notifies clients with mbox_chan_received_data(), but it does not explicitly mark the transmit as complete. In IRQ completion mode this could leave Tx complete waiters hanging or lead to generic timeouts in the mailbox core. Invoke mbox_chan_txdone() in the IRQ path once the platform has acknowledged the transfer so the core can wake any waiters and update state accordingly. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:18 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Refactor and simplify check_and_ack() The existing check_and_ack() function had unnecessary complexity. The logic could be streamlined to improve code readability and maintainability. The command update register needs to be updated in order to acknowledge the platform notification through type 4 channel. So it can be done unconditionally. Currently it is complicated just to make use of pcc_send_data() which also executes the same updation. In order to simplify, let us just ring the doorbell directly from check_and_ack() instead of calling into pcc_send_data(). While at it, rename it into pcc_chan_check_and_ack() to maintain consistency in the driver. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:54 +00:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Check shared memory signature on request ACPI 6.6 Tables 14.9 and 14.12 define the PCC shared memory signature as the bitwise OR of 0x50434300 and the PCC subspace ID. They also clarify that the signature is populated by the platform and verified by OSPM. The signature is at byte offset 0 in the generic, extended and reduced PCC shared memory layouts. Check the signature when a client requests a PCC mailbox channel, after mapping shared memory and before binding the mailbox client. This keeps the check in the PCC mailbox controller instead of duplicating it in individual clients. Treat a signature mismatch as a warning rather than rejecting the channel request. Making this newly added check fatal could break existing systems whose firmware did not populate the signature correctly even though PCC communication works. Continue to reject shared memory that is too small to contain a signature because it cannot be inspected safely. Cc: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested_by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:27 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Always map the shared memory communication address Currently the shared memory communication address was mapped by the mailbox client drivers leading to all sorts of inconsistencies. It also has resulted in the inconsistent attributes used while mapping the shared memory regions. In order to remove/eliminate any issues, let us ensures the shared memory address is always mapped and unmapped when the PCC channels are requested and release. We need to map them as the ACPI PCCT associates these shared memory with each channel subspace and may need use the status or the flags in the headers of those shared memory communication address regions to manage the transport/channel. Note, until all the drivers using PCC start using this mapped shmem, there might be double mapping of the shared memory address. This shouldn't have any impact on existing mbox client drivers. Since there are no users of pcc_chan_ioremap() and also it is mapped by default, we can stop exporting it and merge the functionality into pcc_mbox_request_channel(). Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:53 +00:00
mailbox: pcc: Refactor all PCC channel information into a structure Currently all the PCC channel specific information are stored/maintained in global individual arrays for each of those information. It is not scalable and not clean if we have to stash more channel specific information. Couple of reasons to stash more information are to extend the support to Type 3/4 PCCT subspace and also to avoid accessing the PCCT table entries themselves each time we need the information. This patch moves all those PCC channel specific information into a separate structure pcc_chan_info. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:46 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use mbox_bind_client Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-10 09:16:54 -07:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Avoid using the uninitialized variable 'dev' Smatch static checker warns: | drivers/mailbox/pcc.c:292 pcc_mbox_request_channel() | error: uninitialized symbol 'dev'. Fix the same by using pr_err instead of dev_err as the variable 'dev' is uninitialized at that stage. Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe") Cc: Jassi Brar <jassisinghbrar@gmail.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-12-09 08:21:43 +00:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Always map the shared memory communication address Currently the shared memory communication address was mapped by the mailbox client drivers leading to all sorts of inconsistencies. It also has resulted in the inconsistent attributes used while mapping the shared memory regions. In order to remove/eliminate any issues, let us ensures the shared memory address is always mapped and unmapped when the PCC channels are requested and release. We need to map them as the ACPI PCCT associates these shared memory with each channel subspace and may need use the status or the flags in the headers of those shared memory communication address regions to manage the transport/channel. Note, until all the drivers using PCC start using this mapped shmem, there might be double mapping of the shared memory address. This shouldn't have any impact on existing mbox client drivers. Since there are no users of pcc_chan_ioremap() and also it is mapped by default, we can stop exporting it and merge the functionality into pcc_mbox_request_channel(). Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:53 +00:00
mailbox: pcc: Initialize SHMEM before binding the channel with the client The PCC channel's shared memory region must be set up before the mailbox controller binds the channel with the client, as the binding process may trigger client operations like startup() that may rely on SHMEM being initialized. Reorder the setup sequence to ensure the shared memory is ready before binding. Initialize and map the PCC shared memory (SHMEM) prior to calling mbox_bind_client() so that clients never observe an uninitialized or NULL SHMEM during bind-time callbacks or early use in startup(). This makes the PCC mailbox channel bring-up order consistent and eliminates a race between SHMEM setup and client binding. This will be needed in channel startup to clear/acknowledge any pending interrupts before enabling them. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: lihuisong@huawei.com Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:19 +01:00
mailbox: pcc: Always map the shared memory communication address Currently the shared memory communication address was mapped by the mailbox client drivers leading to all sorts of inconsistencies. It also has resulted in the inconsistent attributes used while mapping the shared memory regions. In order to remove/eliminate any issues, let us ensures the shared memory address is always mapped and unmapped when the PCC channels are requested and release. We need to map them as the ACPI PCCT associates these shared memory with each channel subspace and may need use the status or the flags in the headers of those shared memory communication address regions to manage the transport/channel. Note, until all the drivers using PCC start using this mapped shmem, there might be double mapping of the shared memory address. This shouldn't have any impact on existing mbox client drivers. Since there are no users of pcc_chan_ioremap() and also it is mapped by default, we can stop exporting it and merge the functionality into pcc_mbox_request_channel(). Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-03-13 15:28:53 +00:00
mailbox: pcc: Check shared memory signature on request ACPI 6.6 Tables 14.9 and 14.12 define the PCC shared memory signature as the bitwise OR of 0x50434300 and the PCC subspace ID. They also clarify that the signature is populated by the platform and verified by OSPM. The signature is at byte offset 0 in the generic, extended and reduced PCC shared memory layouts. Check the signature when a client requests a PCC mailbox channel, after mapping shared memory and before binding the mailbox client. This keeps the check in the PCC mailbox controller instead of duplicating it in individual clients. Treat a signature mismatch as a warning rather than rejecting the channel request. Making this newly added check fatal could break existing systems whose firmware did not populate the signature correctly even though PCC communication works. Continue to reject shared memory that is too small to contain a signature because it cannot be inspected safely. Cc: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested_by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:27 +01:00
mailbox: pcc: Initialize SHMEM before binding the channel with the client The PCC channel's shared memory region must be set up before the mailbox controller binds the channel with the client, as the binding process may trigger client operations like startup() that may rely on SHMEM being initialized. Reorder the setup sequence to ensure the shared memory is ready before binding. Initialize and map the PCC shared memory (SHMEM) prior to calling mbox_bind_client() so that clients never observe an uninitialized or NULL SHMEM during bind-time callbacks or early use in startup(). This makes the PCC mailbox channel bring-up order consistent and eliminates a race between SHMEM setup and client binding. This will be needed in channel startup to clear/acknowledge any pending interrupts before enabling them. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: lihuisong@huawei.com Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:19 +01:00
mailbox: pcc: Check shared memory signature on request ACPI 6.6 Tables 14.9 and 14.12 define the PCC shared memory signature as the bitwise OR of 0x50434300 and the PCC subspace ID. They also clarify that the signature is populated by the platform and verified by OSPM. The signature is at byte offset 0 in the generic, extended and reduced PCC shared memory layouts. Check the signature when a client requests a PCC mailbox channel, after mapping shared memory and before binding the mailbox client. This keeps the check in the PCC mailbox controller instead of duplicating it in individual clients. Treat a signature mismatch as a warning rather than rejecting the channel request. Making this newly added check fatal could break existing systems whose firmware did not populate the signature correctly even though PCC communication works. Continue to reject shared memory that is too small to contain a signature because it cannot be inspected safely. Cc: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested_by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:27 +01:00
mailbox: pcc: Initialize SHMEM before binding the channel with the client The PCC channel's shared memory region must be set up before the mailbox controller binds the channel with the client, as the binding process may trigger client operations like startup() that may rely on SHMEM being initialized. Reorder the setup sequence to ensure the shared memory is ready before binding. Initialize and map the PCC shared memory (SHMEM) prior to calling mbox_bind_client() so that clients never observe an uninitialized or NULL SHMEM during bind-time callbacks or early use in startup(). This makes the PCC mailbox channel bring-up order consistent and eliminates a race between SHMEM setup and client binding. This will be needed in channel startup to clear/acknowledge any pending interrupts before enabling them. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: lihuisong@huawei.com Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:19 +01:00
mailbox: pcc: Check shared memory signature on request ACPI 6.6 Tables 14.9 and 14.12 define the PCC shared memory signature as the bitwise OR of 0x50434300 and the PCC subspace ID. They also clarify that the signature is populated by the platform and verified by OSPM. The signature is at byte offset 0 in the generic, extended and reduced PCC shared memory layouts. Check the signature when a client requests a PCC mailbox channel, after mapping shared memory and before binding the mailbox client. This keeps the check in the PCC mailbox controller instead of duplicating it in individual clients. Treat a signature mismatch as a warning rather than rejecting the channel request. Making this newly added check fatal could break existing systems whose firmware did not populate the signature correctly even though PCC communication works. Continue to reject shared memory that is too small to contain a signature because it cannot be inspected safely. Cc: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested_by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:27 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use PCC mailbox channel pointer instead of standard Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:50 +01:00
mailbox: pcc: Check before sending MCTP PCC response ACK Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-20 14:02:14 -05:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Check before sending MCTP PCC response ACK Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-20 14:02:14 -05:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Use mbox_bind_client Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-10 09:16:54 -07:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
Revert "mailbox/pcc: support mailbox management of the shared buffer" This reverts commit 5378bdf6a611a32500fccf13d14156f219bb0c85. Commit 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") attempted to introduce generic helpers for managing the PCC shared memory, but it largely duplicates functionality already provided by the mailbox core and leaves gaps: 1. TX preparation: The mailbox framework already supports this via ->tx_prepare callback for mailbox clients. The patch adds pcc_write_to_buffer() and expects clients to toggle pchan->chan.manage_writes, but no drivers set manage_writes, so pcc_write_to_buffer() has no users. 2. RX handling: Data reception is already delivered through mbox_chan_received_data() and client ->rx_callback. The patch adds an optional pchan->chan.rx_alloc, which again has no users and duplicates the existing path. 3. Completion handling: While adding last_tx_done is directionally useful, the implementation only covers Type 3/4 and fails to handle the absence of a command_complete register, so it is incomplete for other types. Given the duplication and incomplete coverage, revert this change. Any new requirements should be addressed in focused follow-ups rather than bundling multiple behavioral changes together. Fixes: 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:15 +01:00
Mailbox: Restructure and simplify PCC mailbox code Previously the PCC driver depended on the client side to map the communication space base address. This region was was then used in the PCC driver and the client side. The client side used this region to read and write its data and the PCC driver used it to only write the PCC command. Removing this split simplifies the PCC driver a lot. This patch moves all communication region read/writes to the client side. The PCC clients can now drive the PCC mailbox controller via the mbox_client_txdone() method. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
2015-01-27 16:03:57 -05:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
Mailbox: Restructure and simplify PCC mailbox code Previously the PCC driver depended on the client side to map the communication space base address. This region was was then used in the PCC driver and the client side. The client side used this region to read and write its data and the PCC driver used it to only write the PCC command. Removing this split simplifies the PCC driver a lot. This patch moves all communication region read/writes to the client side. The PCC clients can now drive the PCC mailbox controller via the mbox_client_txdone() method. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
2015-01-27 16:03:57 -05:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Fix command timeout due to missed interrupt PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:28 +01:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Fix command timeout due to missed interrupt PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:28 +01:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Wire up ->last_tx_done() for PCC channels Some PCC users poll for completion between transfers and benefit from the knowledge of previous Tx completion check through the mailbox framework's ->last_tx_done() op. Hook up the last_tx_done callback in the PCC mailbox driver so the mailbox framework can correctly query the completion status of the last transmitted message. This aligns PCC with other controllers that already implement such last_tx_done status query. No functional change unless callers use ->last_tx_done(). Normal Tx and IRQ paths are unchanged. This change just improves synchronization and avoids unnecessary timeouts for non-interrupt driven channels by ensuring correct completion detection for PCC channels that don’t rely on interrupts. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:16 +01:00
mailbox: pcc: Notify clients on polled completion PCC channels without a platform interrupt rely on the mailbox polling path to detect command completion. That path currently only reports transmit completion to the mailbox core, so clients that wait for their receive callback do not get notified when the command completes. Call mbox_chan_received_data() when polling observes completion on a channel without a platform IRQ, matching the interrupt-driven completion path. Reported-by: Cristian Marussi <cristian.marussi@arm.com> Acked-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Reviewed-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-07-23 15:39:26 +01:00
mailbox: pcc: Wire up ->last_tx_done() for PCC channels Some PCC users poll for completion between transfers and benefit from the knowledge of previous Tx completion check through the mailbox framework's ->last_tx_done() op. Hook up the last_tx_done callback in the PCC mailbox driver so the mailbox framework can correctly query the completion status of the last transmitted message. This aligns PCC with other controllers that already implement such last_tx_done status query. No functional change unless callers use ->last_tx_done(). Normal Tx and IRQ paths are unchanged. This change just improves synchronization and avoids unnecessary timeouts for non-interrupt driven channels by ensuring correct completion detection for PCC channels that don’t rely on interrupts. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:16 +01:00
mailbox: pcc: Use mbox_bind_client Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-10 09:16:54 -07:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Use mbox_bind_client Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-10 09:16:54 -07:00
mailbox: pcc: Clear any pending responder interrupts before enabling it Some platforms may leave a responder interrupt pending from earlier transactions. If a PCC responder channel has a pending interrupt when the controller starts up, enabling the IRQ line without first clearing the condition can lead to a spurious interrupt which could disrupt other transmissions if the IRQ is shared. Explicitly clear any pending responder interrupt before enabling the IRQ to ensure a clean start. Acknowledge the responder channel via pcc_chan_acknowledge() in startup before requesting/enablement of the IRQ. This ensures a clean baseline for the first transfer/receiption of the notification/response. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:20 +01:00
mailbox: pcc: Use mbox_bind_client Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-10 09:16:54 -07:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Remove spurious IRQF_ONESHOT usage The PCC code currently specifies IRQF_ONESHOT if the interrupt could potentially be shared but doesn't actually use request_threaded_irq() and the interrupt handler does not use IRQ_WAKE_THREAD so IRQF_ONESHOT is never relevant. Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler") specifying it has resulted in a WARN_ON(), fix this by removing IRQF_ONESHOT. Reported-by: Aishwarya TCV <Aishwarya.TCV@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2026-01-16 14:07:40 +00:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Use mbox_bind_client Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-10 09:16:54 -07:00
mailbox: Make mbox_chan_ops const The mailbox controller's channel ops ought to be read-only. Update all the mailbox drivers to make their mbox_chan_ops const as well. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Cc: Ashwin Chaugule <ashwin.chaugule@linaro.org> Cc: Ley Foon Tan <lftan@altera.com> Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2015-05-04 10:36:35 -07:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Use mbox_bind_client Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-10 09:16:54 -07:00
mailbox: pcc: Wire up ->last_tx_done() for PCC channels Some PCC users poll for completion between transfers and benefit from the knowledge of previous Tx completion check through the mailbox framework's ->last_tx_done() op. Hook up the last_tx_done callback in the PCC mailbox driver so the mailbox framework can correctly query the completion status of the last transmitted message. This aligns PCC with other controllers that already implement such last_tx_done status query. No functional change unless callers use ->last_tx_done(). Normal Tx and IRQ paths are unchanged. This change just improves synchronization and avoids unnecessary timeouts for non-interrupt driven channels by ensuring correct completion detection for PCC channels that don’t rely on interrupts. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:16 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Fix kernel doc warnings Kernel doc validation script is unhappy and complains with the below set of warnings. | drivers/mailbox/pcc.c:179: warning: Function parameter or member 'irq' | not described in 'pcc_mbox_irq' | drivers/mailbox/pcc.c:179: warning: Function parameter or member 'p' | not described in 'pcc_mbox_irq' | drivers/mailbox/pcc.c:378: warning: expecting prototype for | parse_pcc_subspaces(). Prototype was for parse_pcc_subspace() instead Fix it. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:44 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: PCC: erroneous error message when parsing ACPI PCCT There have been multiple reports of the following error message: [ 0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that acpi_pcc_probe() which reads the PCCT is making the assumption that the only valid PCCT is one that contains subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these types are counted and as long as there is at least one of the desired types, the acpi_pcc_probe() succeeds. When no subtables of these types are found, regardless of whether or not any other subtable types are present, the error mentioned above is reported. In the cases reported to me personally, the PCCT contains exactly one subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function acpi_pcc_probe() does not count it as a valid subtable, so believes there to be no valid subtables, and hence outputs the error message. An example of the PCCT being reported as erroneous yet perfectly fine is the following: Signature : "PCCT" Table Length : 0000006E Revision : 05 Checksum : A9 Oem ID : "XXXXXX" Oem Table ID : "XXXXX " Oem Revision : 00002280 Asl Compiler ID : "XXXX" Asl Compiler Revision : 00000002 Flags (decoded below) : 00000001 Platform : 1 Reserved : 0000000000000000 Subtable Type : 00 [Generic Communications Subspace] Length : 3E Reserved : 000000000000 Base Address : 00000000DCE43018 Address Length : 0000000000001000 Doorbell Register : [Generic Address Structure] Space ID : 01 [SystemIO] Bit Width : 08 Bit Offset : 00 Encoded Access Width : 01 [Byte Access:8] Address : 0000000000001842 Preserve Mask : 00000000000000FD Write Mask : 0000000000000002 Command Latency : 00001388 Maximum Access Rate : 00000000 Minimum Turnaround Time : 0000 To fix this, we count up all of the possible subtable types for the PCCT, and only report an error when there are none (which could mean either no subtables, or no valid subtables), or there are too many. We also change the logic so that if there is a valid subtable, we do try to initialize it per the PCCT subtable contents. This is a change in functionality; previously, the probe would have returned right after the error message and would not have tried to use any other subtable definition. Tested on my personal laptop which showed the error previously; the error message no longer appears and the laptop appears to operate normally. Signed-off-by: Al Stone <ahs3@redhat.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 16:01:41 -06:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
acpi: Create subtable parsing infrastructure Parsing entries in an ACPI table had assumed a generic header structure. There is no standard ACPI header, though, so less common layouts with different field sizes required custom parsers to go through their subtable entry list. Create the infrastructure for adding different table types so parsing the entries array may be more reused for all ACPI system tables and the common code doesn't need to be duplicated. Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Tested-by: Brice Goglin <Brice.Goglin@inria.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-11 14:55:57 -06:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: PCC: erroneous error message when parsing ACPI PCCT There have been multiple reports of the following error message: [ 0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that acpi_pcc_probe() which reads the PCCT is making the assumption that the only valid PCCT is one that contains subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these types are counted and as long as there is at least one of the desired types, the acpi_pcc_probe() succeeds. When no subtables of these types are found, regardless of whether or not any other subtable types are present, the error mentioned above is reported. In the cases reported to me personally, the PCCT contains exactly one subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function acpi_pcc_probe() does not count it as a valid subtable, so believes there to be no valid subtables, and hence outputs the error message. An example of the PCCT being reported as erroneous yet perfectly fine is the following: Signature : "PCCT" Table Length : 0000006E Revision : 05 Checksum : A9 Oem ID : "XXXXXX" Oem Table ID : "XXXXX " Oem Revision : 00002280 Asl Compiler ID : "XXXX" Asl Compiler Revision : 00000002 Flags (decoded below) : 00000001 Platform : 1 Reserved : 0000000000000000 Subtable Type : 00 [Generic Communications Subspace] Length : 3E Reserved : 000000000000 Base Address : 00000000DCE43018 Address Length : 0000000000001000 Doorbell Register : [Generic Address Structure] Space ID : 01 [SystemIO] Bit Width : 08 Bit Offset : 00 Encoded Access Width : 01 [Byte Access:8] Address : 0000000000001842 Preserve Mask : 00000000000000FD Write Mask : 0000000000000002 Command Latency : 00001388 Maximum Access Rate : 00000000 Minimum Turnaround Time : 0000 To fix this, we count up all of the possible subtable types for the PCCT, and only report an error when there are none (which could mean either no subtables, or no valid subtables), or there are too many. We also change the logic so that if there is a valid subtable, we do try to initialize it per the PCCT subtable contents. This is a change in functionality; previously, the probe would have returned right after the error message and would not have tried to use any other subtable definition. Tested on my personal laptop which showed the error previously; the error message no longer appears and the laptop appears to operate normally. Signed-off-by: Al Stone <ahs3@redhat.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 16:01:41 -06:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: PCC: erroneous error message when parsing ACPI PCCT There have been multiple reports of the following error message: [ 0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that acpi_pcc_probe() which reads the PCCT is making the assumption that the only valid PCCT is one that contains subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these types are counted and as long as there is at least one of the desired types, the acpi_pcc_probe() succeeds. When no subtables of these types are found, regardless of whether or not any other subtable types are present, the error mentioned above is reported. In the cases reported to me personally, the PCCT contains exactly one subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function acpi_pcc_probe() does not count it as a valid subtable, so believes there to be no valid subtables, and hence outputs the error message. An example of the PCCT being reported as erroneous yet perfectly fine is the following: Signature : "PCCT" Table Length : 0000006E Revision : 05 Checksum : A9 Oem ID : "XXXXXX" Oem Table ID : "XXXXX " Oem Revision : 00002280 Asl Compiler ID : "XXXX" Asl Compiler Revision : 00000002 Flags (decoded below) : 00000001 Platform : 1 Reserved : 0000000000000000 Subtable Type : 00 [Generic Communications Subspace] Length : 3E Reserved : 000000000000 Base Address : 00000000DCE43018 Address Length : 0000000000001000 Doorbell Register : [Generic Address Structure] Space ID : 01 [SystemIO] Bit Width : 08 Bit Offset : 00 Encoded Access Width : 01 [Byte Access:8] Address : 0000000000001842 Preserve Mask : 00000000000000FD Write Mask : 0000000000000002 Command Latency : 00001388 Maximum Access Rate : 00000000 Minimum Turnaround Time : 0000 To fix this, we count up all of the possible subtable types for the PCCT, and only report an error when there are none (which could mean either no subtables, or no valid subtables), or there are too many. We also change the logic so that if there is a valid subtable, we do try to initialize it per the PCCT subtable contents. This is a change in functionality; previously, the probe would have returned right after the error message and would not have tried to use any other subtable definition. Tested on my personal laptop which showed the error previously; the error message no longer appears and the laptop appears to operate normally. Signed-off-by: Al Stone <ahs3@redhat.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 16:01:41 -06:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: PCC: erroneous error message when parsing ACPI PCCT There have been multiple reports of the following error message: [ 0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that acpi_pcc_probe() which reads the PCCT is making the assumption that the only valid PCCT is one that contains subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these types are counted and as long as there is at least one of the desired types, the acpi_pcc_probe() succeeds. When no subtables of these types are found, regardless of whether or not any other subtable types are present, the error mentioned above is reported. In the cases reported to me personally, the PCCT contains exactly one subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function acpi_pcc_probe() does not count it as a valid subtable, so believes there to be no valid subtables, and hence outputs the error message. An example of the PCCT being reported as erroneous yet perfectly fine is the following: Signature : "PCCT" Table Length : 0000006E Revision : 05 Checksum : A9 Oem ID : "XXXXXX" Oem Table ID : "XXXXX " Oem Revision : 00002280 Asl Compiler ID : "XXXX" Asl Compiler Revision : 00000002 Flags (decoded below) : 00000001 Platform : 1 Reserved : 0000000000000000 Subtable Type : 00 [Generic Communications Subspace] Length : 3E Reserved : 000000000000 Base Address : 00000000DCE43018 Address Length : 0000000000001000 Doorbell Register : [Generic Address Structure] Space ID : 01 [SystemIO] Bit Width : 08 Bit Offset : 00 Encoded Access Width : 01 [Byte Access:8] Address : 0000000000001842 Preserve Mask : 00000000000000FD Write Mask : 0000000000000002 Command Latency : 00001388 Maximum Access Rate : 00000000 Minimum Turnaround Time : 0000 To fix this, we count up all of the possible subtable types for the PCCT, and only report an error when there are none (which could mean either no subtables, or no valid subtables), or there are too many. We also change the logic so that if there is a valid subtable, we do try to initialize it per the PCCT subtable contents. This is a change in functionality; previously, the probe would have returned right after the error message and would not have tried to use any other subtable definition. Tested on my personal laptop which showed the error previously; the error message no longer appears and the laptop appears to operate normally. Signed-off-by: Al Stone <ahs3@redhat.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 16:01:41 -06:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Add PCC register bundle and associated accessor functions Extended PCC subspaces introduces more registers into the PCCT. In order to consolidate access to these registers and to keep all the details contained in one place, let us introduce PCC register bundle that holds the ACPI Generic Address Structure as well as the virtual address for the same if it is mapped in the OS. It also contains the various masks used to access the register and the associated read, write and read-modify-write accessors. We can also clean up the initialisations by having a helper function for the same. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:52 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Consolidate subspace interrupt information parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the IRQ related information parsing into pcc_parse_subspace_irq and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:47 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Consolidate subspace interrupt information parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the IRQ related information parsing into pcc_parse_subspace_irq and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:47 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Consolidate subspace interrupt information parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the IRQ related information parsing into pcc_parse_subspace_irq and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:47 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Consolidate subspace interrupt information parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the IRQ related information parsing into pcc_parse_subspace_irq and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:47 +01:00
mailbox: pcc: Refactor all PCC channel information into a structure Currently all the PCC channel specific information are stored/maintained in global individual arrays for each of those information. It is not scalable and not clean if we have to stash more channel specific information. Couple of reasons to stash more information are to extend the support to Type 3/4 PCCT subspace and also to avoid accessing the PCCT table entries themselves each time we need the information. This patch moves all those PCC channel specific information into a separate structure pcc_chan_info. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:46 +01:00
mailbox: pcc: Consolidate subspace interrupt information parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the IRQ related information parsing into pcc_parse_subspace_irq and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:47 +01:00
mailbox: pcc: Rename doorbell ack to platform interrupt ack register The specification refers this register and associated bitmask as platform interrupt acknowledge register. Let us rename it so that it is easier to map and understand. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:51 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
ACPICA: Add support for new PCCT subtables ACPICA commit e7b817e3c405a4fb9ae9ee7ae4992b8c1f20d284 Extended PCC Subspaces (types 3 and 4) Link: https://github.com/acpica/acpica/commit/e7b817e3 Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-05 16:39:08 +08:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Consolidate subspace interrupt information parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the IRQ related information parsing into pcc_parse_subspace_irq and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:47 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Support shared interrupt for multiple subspaces If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:27 +08:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
mailbox: pcc: Consolidate subspace doorbell register parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the doorbell register parsing into pcc_parse_subspace_db_reg and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:48 +01:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Consolidate subspace doorbell register parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the doorbell register parsing into pcc_parse_subspace_db_reg and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:48 +01:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Consolidate subspace doorbell register parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the doorbell register parsing into pcc_parse_subspace_db_reg and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:48 +01:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Consolidate subspace doorbell register parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the doorbell register parsing into pcc_parse_subspace_db_reg and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:48 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Consolidate subspace doorbell register parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the doorbell register parsing into pcc_parse_subspace_db_reg and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:48 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: don't zero error register The error status mask for a type 3/4 subspace is used for reading the error status, and the bitwise inverse is used for clearing the error with the intent being to preserve any of the non-error bits. However, we were previously applying the mask to extract the status and then applying the inverse to the result which ended up clearing all bits. Instead, store the inverse mask in the preserve mask and then use that on the original value read from the error status so that only the error is cleared. Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Signed-off-by: Jamie Iles <jamie.iles@oss.qualcomm.com> Signed-off-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-11-05 14:42:29 +00:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Avoid accessing PCCT table in pcc_send_data and pcc_mbox_irq Now that the con_priv is availvale solely for PCC mailbox controller driver, let us use the same to save the channel specific information in it so that we can it whenever required instead of parsing the PCCT table entries every time in both pcc_send_data and pcc_mbox_irq. We can now use the newly introduces PCC register bundle to simplify both saving of channel specific information and accessing them without repeated checks for the subspace type. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:53 +01:00
mailbox: pcc: Consolidate subspace doorbell register parsing Extended PCC subspaces(Type 3 and 4) differ from generic(Type 0) and HW-Reduced Communication(Type 1 and 2) subspace structures. However some fields share same offsets and same type of structure can be use to extract the fields. In order to simplify that, let us move all the doorbell register parsing into pcc_parse_subspace_db_reg and consolidate there. It will be easier to extend it if required within the same. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:48 +01:00
mailbox: pcc: Add pcc_mbox_chan structure to hold shared memory region info Currently PCC mailbox controller sets con_priv in each channel to hold the pointer to pcct subspace entry it corresponds to. The mailbox user will then fetch this pointer from the channel descriptor they get when they request for the channel. Using that pointer they then parse the pcct entry again to fetch all the information about shared memory region. In order to remove individual users of PCC mailbox parsing the PCCT subspace entries to fetch same information, let us consolidate the same in pcc mailbox controller by parsing all the shared memory region information into a structure that can also hold the mbox_chan pointer it represent. This can then be used as main PCC mailbox channel pointer that we can return as part of pcc_mbox_request_channel instead of standard mailbox channel pointer. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:49 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Add pcc_mbox_chan structure to hold shared memory region info Currently PCC mailbox controller sets con_priv in each channel to hold the pointer to pcct subspace entry it corresponds to. The mailbox user will then fetch this pointer from the channel descriptor they get when they request for the channel. Using that pointer they then parse the pcct entry again to fetch all the information about shared memory region. In order to remove individual users of PCC mailbox parsing the PCCT subspace entries to fetch same information, let us consolidate the same in pcc mailbox controller by parsing all the shared memory region information into a structure that can also hold the mbox_chan pointer it represent. This can then be used as main PCC mailbox channel pointer that we can return as part of pcc_mbox_request_channel instead of standard mailbox channel pointer. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:49 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Add pcc_mbox_chan structure to hold shared memory region info Currently PCC mailbox controller sets con_priv in each channel to hold the pointer to pcct subspace entry it corresponds to. The mailbox user will then fetch this pointer from the channel descriptor they get when they request for the channel. Using that pointer they then parse the pcct entry again to fetch all the information about shared memory region. In order to remove individual users of PCC mailbox parsing the PCCT subspace entries to fetch same information, let us consolidate the same in pcc mailbox controller by parsing all the shared memory region information into a structure that can also hold the mbox_chan pointer it represent. This can then be used as main PCC mailbox channel pointer that we can return as part of pcc_mbox_request_channel instead of standard mailbox channel pointer. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:49 +01:00
mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:55 +01:00
mailbox: pcc: Add pcc_mbox_chan structure to hold shared memory region info Currently PCC mailbox controller sets con_priv in each channel to hold the pointer to pcct subspace entry it corresponds to. The mailbox user will then fetch this pointer from the channel descriptor they get when they request for the channel. Using that pointer they then parse the pcct entry again to fetch all the information about shared memory region. In order to remove individual users of PCC mailbox parsing the PCCT subspace entries to fetch same information, let us consolidate the same in pcc mailbox controller by parsing all the shared memory region information into a structure that can also hold the mbox_chan pointer it represent. This can then be used as main PCC mailbox channel pointer that we can return as part of pcc_mbox_request_channel instead of standard mailbox channel pointer. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:49 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: PCC: erroneous error message when parsing ACPI PCCT There have been multiple reports of the following error message: [ 0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that acpi_pcc_probe() which reads the PCCT is making the assumption that the only valid PCCT is one that contains subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these types are counted and as long as there is at least one of the desired types, the acpi_pcc_probe() succeeds. When no subtables of these types are found, regardless of whether or not any other subtable types are present, the error mentioned above is reported. In the cases reported to me personally, the PCCT contains exactly one subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function acpi_pcc_probe() does not count it as a valid subtable, so believes there to be no valid subtables, and hence outputs the error message. An example of the PCCT being reported as erroneous yet perfectly fine is the following: Signature : "PCCT" Table Length : 0000006E Revision : 05 Checksum : A9 Oem ID : "XXXXXX" Oem Table ID : "XXXXX " Oem Revision : 00002280 Asl Compiler ID : "XXXX" Asl Compiler Revision : 00000002 Flags (decoded below) : 00000001 Platform : 1 Reserved : 0000000000000000 Subtable Type : 00 [Generic Communications Subspace] Length : 3E Reserved : 000000000000 Base Address : 00000000DCE43018 Address Length : 0000000000001000 Doorbell Register : [Generic Address Structure] Space ID : 01 [SystemIO] Bit Width : 08 Bit Offset : 00 Encoded Access Width : 01 [Byte Access:8] Address : 0000000000001842 Preserve Mask : 00000000000000FD Write Mask : 0000000000000002 Command Latency : 00001388 Maximum Access Rate : 00000000 Minimum Turnaround Time : 0000 To fix this, we count up all of the possible subtable types for the PCCT, and only report an error when there are none (which could mean either no subtables, or no valid subtables), or there are too many. We also change the logic so that if there is a valid subtable, we do try to initialize it per the PCCT subtable contents. This is a change in functionality; previously, the probe would have returned right after the error message and would not have tried to use any other subtable definition. Tested on my personal laptop which showed the error previously; the error message no longer appears and the laptop appears to operate normally. Signed-off-by: Al Stone <ahs3@redhat.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 16:01:41 -06:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users This patch removes the users of the deprectated APIs: acpi_get_table_with_size() early_acpi_os_unmap_memory() The following APIs should be used instead of: acpi_get_table() acpi_put_table() The deprecated APIs are invented to be a replacement of acpi_get_table() during the early stage so that the early mapped pointer will not be stored in ACPICA core and thus the late stage acpi_get_table() won't return a wrong pointer. The mapping size is returned just because it is required by early_acpi_os_unmap_memory() to unmap the pointer during early stage. But as the mapping size equals to the acpi_table_header.length (see acpi_tb_init_table_descriptor() and acpi_tb_validate_table()), when such a convenient result is returned, driver code will start to use it instead of accessing acpi_table_header to obtain the length. Thus this patch cleans up the drivers by replacing returned table size with acpi_table_header.length, and should be a no-op. Reported-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-14 15:04:39 +08:00
mailbox: pcc: Drop uninformative output during boot When booting on an ACPI enabled system that does not provide the Platform Communications Channel Table (PCCT), the pcc mailbox driver prints - [ 0.484261] PCCT header not found. during probe before returning -ENODEV. This message clutters the bootlog and doesn't provide any useful information. Drop this message. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Alexey Klimov <alexey.klimov@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-01 13:43:57 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: PCC: erroneous error message when parsing ACPI PCCT There have been multiple reports of the following error message: [ 0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that acpi_pcc_probe() which reads the PCCT is making the assumption that the only valid PCCT is one that contains subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these types are counted and as long as there is at least one of the desired types, the acpi_pcc_probe() succeeds. When no subtables of these types are found, regardless of whether or not any other subtable types are present, the error mentioned above is reported. In the cases reported to me personally, the PCCT contains exactly one subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function acpi_pcc_probe() does not count it as a valid subtable, so believes there to be no valid subtables, and hence outputs the error message. An example of the PCCT being reported as erroneous yet perfectly fine is the following: Signature : "PCCT" Table Length : 0000006E Revision : 05 Checksum : A9 Oem ID : "XXXXXX" Oem Table ID : "XXXXX " Oem Revision : 00002280 Asl Compiler ID : "XXXX" Asl Compiler Revision : 00000002 Flags (decoded below) : 00000001 Platform : 1 Reserved : 0000000000000000 Subtable Type : 00 [Generic Communications Subspace] Length : 3E Reserved : 000000000000 Base Address : 00000000DCE43018 Address Length : 0000000000001000 Doorbell Register : [Generic Address Structure] Space ID : 01 [SystemIO] Bit Width : 08 Bit Offset : 00 Encoded Access Width : 01 [Byte Access:8] Address : 0000000000001842 Preserve Mask : 00000000000000FD Write Mask : 0000000000000002 Command Latency : 00001388 Maximum Access Rate : 00000000 Minimum Turnaround Time : 0000 To fix this, we count up all of the possible subtable types for the PCCT, and only report an error when there are none (which could mean either no subtables, or no valid subtables), or there are too many. We also change the logic so that if there is a valid subtable, we do try to initialize it per the PCCT subtable contents. This is a change in functionality; previously, the probe would have returned right after the error message and would not have tried to use any other subtable definition. Tested on my personal laptop which showed the error previously; the error message no longer appears and the laptop appears to operate normally. Signed-off-by: Al Stone <ahs3@redhat.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 16:01:41 -06:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: PCC: erroneous error message when parsing ACPI PCCT There have been multiple reports of the following error message: [ 0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that acpi_pcc_probe() which reads the PCCT is making the assumption that the only valid PCCT is one that contains subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these types are counted and as long as there is at least one of the desired types, the acpi_pcc_probe() succeeds. When no subtables of these types are found, regardless of whether or not any other subtable types are present, the error mentioned above is reported. In the cases reported to me personally, the PCCT contains exactly one subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function acpi_pcc_probe() does not count it as a valid subtable, so believes there to be no valid subtables, and hence outputs the error message. An example of the PCCT being reported as erroneous yet perfectly fine is the following: Signature : "PCCT" Table Length : 0000006E Revision : 05 Checksum : A9 Oem ID : "XXXXXX" Oem Table ID : "XXXXX " Oem Revision : 00002280 Asl Compiler ID : "XXXX" Asl Compiler Revision : 00000002 Flags (decoded below) : 00000001 Platform : 1 Reserved : 0000000000000000 Subtable Type : 00 [Generic Communications Subspace] Length : 3E Reserved : 000000000000 Base Address : 00000000DCE43018 Address Length : 0000000000001000 Doorbell Register : [Generic Address Structure] Space ID : 01 [SystemIO] Bit Width : 08 Bit Offset : 00 Encoded Access Width : 01 [Byte Access:8] Address : 0000000000001842 Preserve Mask : 00000000000000FD Write Mask : 0000000000000002 Command Latency : 00001388 Maximum Access Rate : 00000000 Minimum Turnaround Time : 0000 To fix this, we count up all of the possible subtable types for the PCCT, and only report an error when there are none (which could mean either no subtables, or no valid subtables), or there are too many. We also change the logic so that if there is a valid subtable, we do try to initialize it per the PCCT subtable contents. This is a change in functionality; previously, the probe would have returned right after the error message and would not have tried to use any other subtable definition. Tested on my personal laptop which showed the error previously; the error message no longer appears and the laptop appears to operate normally. Signed-off-by: Al Stone <ahs3@redhat.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 16:01:41 -06:00
mailbox: PCC: handle parse error acpi_pcc_probe() calls acpi_table_parse_entries_array() but fails to check for an error return. This in turn can result in calling kcalloc() with a negative count as well as emitting the following misleading erorr message: [ 2.642015] Could not allocate space for PCC mbox channels Fixes: 8f8027c5f935 (mailbox: PCC: erroneous error message when parsing ACPI PCCT) Signed-off-by: David Arcari <darcari@redhat.com> Reviewed-by: Al Stone <ahs3@redhat.com> Cc: 4.18+ <stable@vger.kernel.org> # 4.18+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-08-27 15:19:08 -04:00
mailbox: pcc: Put the PCCT table for error path The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used at runtime to release the table mapping. In acpi_pcc_probe(), the PCCT table entries will be used as private data for communication chan at runtime, but the table should be put for error path. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2020-07-22 17:40:40 +08:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Put the PCCT table for error path The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used at runtime to release the table mapping. In acpi_pcc_probe(), the PCCT table entries will be used as private data for communication chan at runtime, but the table should be put for error path. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2020-07-22 17:40:40 +08:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
mailbox: pcc: Support HW-Reduced Communication Subspace type 2 ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for use on HW-Reduce ACPI Platform, which requires read-modify-write sequence to acknowledge doorbell interrupt. This patch provides the implementation for the Communication Subspace Type 2. Signed-off-by: Hoan Tran <hotran@apm.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-15 17:14:05 -07:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
mailbox: pcc: Fix an invalid-load caught by the address sanitizer `pcc_mailbox_probe` doesn't initialize all memory that has been allocated before the first time that one of it's members `txdone_irq` may be accessed. This leads to a an invalid load any time that this member is accessed: [ 2.429769] UBSAN: invalid-load in drivers/mailbox/pcc.c:684:22 [ 2.430324] UBSAN: invalid-load in drivers/mailbox/mailbox.c:486:12 [ 4.276782] UBSAN: invalid-load in drivers/acpi/cppc_acpi.c:314:45 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215587 Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2022-05-09 09:17:16 -05:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
mailbox: pcc: Set txdone_irq/txdone_poll based on PCCT flags The PCC controller currently enables txdone via IRQ if the PCCT exposes platform capability to generate command completion interrupt, but it leaves txdone_poll unchanged. Make the behaviour explicit: - If ACPI_PCCT_DOORBELL is present, use txdone_irq and disable polling. - Otherwise, disable txdone_irq and fall back to txdone_poll. Configure the PCC mailbox to use interrupt-based completion for PCC types that signal completion via IRQ using TXDONE_BY_IRQ, and fall back to polling for others using TXDONE_BY_POLL. This ensures the PCC driver uses the appropriate completion mechanism according to the PCCT table definition and makes the completion mode unambiguous avoiding mixed signalling when the platform lacks a doorbell flag set. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:17 +01:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
mailbox: pcc: Set txdone_irq/txdone_poll based on PCCT flags The PCC controller currently enables txdone via IRQ if the PCCT exposes platform capability to generate command completion interrupt, but it leaves txdone_poll unchanged. Make the behaviour explicit: - If ACPI_PCCT_DOORBELL is present, use txdone_irq and disable polling. - Otherwise, disable txdone_irq and fall back to txdone_poll. Configure the PCC mailbox to use interrupt-based completion for PCC types that signal completion via IRQ using TXDONE_BY_IRQ, and fall back to polling for others using TXDONE_BY_POLL. This ensures the PCC driver uses the appropriate completion mechanism according to the PCCT table definition and makes the completion mode unambiguous avoiding mixed signalling when the platform lacks a doorbell flag set. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2025-10-16 20:08:17 +01:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
mailbox: pcc: Fix spelling mistake "Plaform" -> "Platform" There is a spelling mistake in a pr_err message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2022-09-28 22:22:57 +01:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
mailbox: pcc: Add support for platform notification handling Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-08-01 14:38:26 +08:00
mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-09-17 14:33:56 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
mailbox: pcc: make pcc_mbox_driver static Fix the following sparse warning: drivers/mailbox/pcc.c:571:24: warning: symbol 'pcc_mbox_driver' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2020-04-03 11:52:08 +08:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
ACPI / PCC: Use pr_debug() for debug messages in pcc_init() pcc_init() uses pr_err() to print two messages that are really debug and not interesting to users. Replace those pr_err() with pr_debug(). Reported-by: Cristian <caravena@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05 00:40:08 +01:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
Mailbox: Fix return value check in pcc_init() In case of error, the function platform_create_bundle() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
2015-01-14 09:10:56 +08:00
ACPI / PCC: Use pr_debug() for debug messages in pcc_init() pcc_init() uses pr_err() to print two messages that are really debug and not interesting to users. Replace those pr_err() with pr_debug(). Reported-by: Cristian <caravena@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05 00:40:08 +01:00
mailbox: pcc: Reset pcc_chan_count to zero in case of PCC probe failure Currently, 'pcc_chan_count' is remains set to a non-zero value if PCC subspaces are parsed successfully but something else fail later during the initial PCC probing phase. This will result in pcc_mbox_request_channel trying to access the resources that are not initialised or allocated and may end up in a system crash. Reset pcc_chan_count to 0 when the PCC probe fails in order to prevent the possible issue as described above. Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe") Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-11-12 10:05:28 +08:00
Mailbox: Fix return value check in pcc_init() In case of error, the function platform_create_bundle() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
2015-01-14 09:10:56 +08:00
Mailbox: Add support for Platform Communication Channel ACPI 5.0+ spec defines a generic mode of communication between the OS and a platform such as the BMC. This medium (PCC) is typically used by CPPC (ACPI CPU Performance management), RAS (ACPI reliability protocol) and MPST (ACPI Memory power states). This patch adds PCC support as a Mailbox Controller. As of ACPI v5.1 there is no provision for clients to lookup mailbox controllers in a way that Linux expects. e.g. in DT the clients can list the mailboxes they can associate with in the DT binding and then provide a unique index to lookup a channel within a mailbox. Since the ACPI spec doesn't have anything similar, we introduce a mailbox controller specific API so that when the client calls it, we know to lookup in the context of a specific controller. This also helps in keeping a consistent interface across DT and ACPI for such drivers. This patch implements basic PCC support using the ACPI v5.1 structures. IRQ mode support will be provided as follow up patches. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-12 19:59:38 -05:00
PCC: Initialize PCC Mailbox earlier at boot This change initializes the PCC Mailbox earlier than the ACPI processor driver. This enables drivers introduced in follow up patches (e.g. CPPC) to be probed via the ACPI processor driver interface. The CPPC probe requires the PCC channel to be initialized for it to query each CPUs performance capabilities. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Al Stone <al.stone@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-08-05 09:40:24 -04:00