| 236f7d80 | 28-Dec-2023 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
platform/x86/amd/pmc: Modify SMU message port for latest AMD platform
The latest platforms use a different SMU message port(0x938) from the one currently being used (0x538). Make code changes to ada
platform/x86/amd/pmc: Modify SMU message port for latest AMD platform
The latest platforms use a different SMU message port(0x938) from the one currently being used (0x538). Make code changes to adapt to this new information.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231228102104.1785383-7-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
| d33e992e | 28-Dec-2023 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
platform/x86/amd/pmc: Add 1Ah family series to STB support list
AMD newer platforms, (AMDI000A or family 1Ah series) also supports the STB functionality. Add this to amd_pmc_is_stb_supported().
Sig
platform/x86/amd/pmc: Add 1Ah family series to STB support list
AMD newer platforms, (AMDI000A or family 1Ah series) also supports the STB functionality. Add this to amd_pmc_is_stb_supported().
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231228102104.1785383-6-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
| 9ae57d88 | 28-Dec-2023 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
platform/x86/amd/pmc: Add idlemask support for 1Ah family
Idlemask is an indication of each IP block current state (i.e. whether it is running or idle) during s2idle transistion. The newer 1Ah famil
platform/x86/amd/pmc: Add idlemask support for 1Ah family
Idlemask is an indication of each IP block current state (i.e. whether it is running or idle) during s2idle transistion. The newer 1Ah family supports this feature, add it to the support list.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231228102104.1785383-5-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
| 13313c13 | 28-Dec-2023 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
platform/x86/amd/pmc: call amd_pmc_get_ip_info() during driver probe
In the current code, amd_pmc_get_ip_info() is being called from amd_pmc_s2d_init() and that code block gets enabled only when the
platform/x86/amd/pmc: call amd_pmc_get_ip_info() during driver probe
In the current code, amd_pmc_get_ip_info() is being called from amd_pmc_s2d_init() and that code block gets enabled only when the STB is being enabled.
But the information from amd_pmc_get_ip_info() will be required outside of STB usecase. Hence move this call into driver probe sequence.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231228102104.1785383-4-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
| d8fb50fe | 28-Dec-2023 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
platform/x86/amd/pmc: Add VPE information for AMDI000A platform
Latest AMD SoCs has VPE (Video Processing Engine) IP block and the statistics related to this IP can be obtained as a part of metrics
platform/x86/amd/pmc: Add VPE information for AMDI000A platform
Latest AMD SoCs has VPE (Video Processing Engine) IP block and the statistics related to this IP can be obtained as a part of metrics table information that the PMFW propogates. Add this support for 1Ah family series.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231228102104.1785383-3-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
| a55bdad5 | 12-Dec-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
platform/x86/amd/pmc: Disable keyboard wakeup on AMD Framework 13
The Laptop 13 (AMD Ryzen 7040Series) BIOS 03.03 has a workaround included in the EC firmware that will cause the EC to emit a "spuri
platform/x86/amd/pmc: Disable keyboard wakeup on AMD Framework 13
The Laptop 13 (AMD Ryzen 7040Series) BIOS 03.03 has a workaround included in the EC firmware that will cause the EC to emit a "spurious" keypress during the resume from s0i3 [1].
This series of keypress events can be observed in the kernel log on resume.
``` atkbd serio0: Unknown key pressed (translated set 2, code 0x6b on isa0060/serio0). atkbd serio0: Use 'setkeycodes 6b <keycode>' to make it known. atkbd serio0: Unknown key released (translated set 2, code 0x6b on isa0060/serio0). atkbd serio0: Use 'setkeycodes 6b <keycode>' to make it known. ```
In some user flows this is harmless, but if a user has specifically suspended the laptop and then closed the lid it will cause the laptop to wakeup. The laptop wakes up because the ACPI SCI triggers when the lid is closed and when the kernel sees that IRQ1 is "also" active. The kernel can't distinguish from a real keyboard keypress and wakes the system.
Add the model into the list of quirks to disable keyboard wakeup source. This is intentionally only matching the production BIOS version in hopes that a newer EC firmware included in a newer BIOS can avoid this behavior.
Cc: Kieran Levin <ktl@framework.net> Link: https://github.com/FrameworkComputer/EmbeddedController/blob/lotus-zephyr/zephyr/program/lotus/azalea/src/power_sequence.c#L313 [1] Link: https://community.frame.work/t/amd-wont-sleep-properly/41755 Link: https://community.frame.work/t/tracking-framework-amd-ryzen-7040-series-lid-wakeup-behavior-feedback/39128 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231212045006.97581-5-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| b614a4bd | 12-Dec-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
platform/x86/amd/pmc: Move keyboard wakeup disablement detection to pmc-quirks
Other platforms may need to disable keyboard wakeup besides Cezanne, so move the detection into amd_pmc_quirks_init() w
platform/x86/amd/pmc: Move keyboard wakeup disablement detection to pmc-quirks
Other platforms may need to disable keyboard wakeup besides Cezanne, so move the detection into amd_pmc_quirks_init() where it may be applied to multiple platforms.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231212045006.97581-4-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| 2d53c0ab | 12-Dec-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
platform/x86/amd/pmc: Only run IRQ1 firmware version check on Cezanne
amd_pmc_wa_czn_irq1() only runs on Cezanne platforms currently but may be extended to other platforms in the future. Rename the
platform/x86/amd/pmc: Only run IRQ1 firmware version check on Cezanne
amd_pmc_wa_czn_irq1() only runs on Cezanne platforms currently but may be extended to other platforms in the future. Rename the function and only check platform firmware version when it's called for a Cezanne based platform.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231212045006.97581-3-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| 3f720b21 | 10-Oct-2023 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
platform/x86/amd/pmc: Add dump_custom_stb module parameter
There have been instances when the default size (1M) of the STB is not sufficient to get the complete traces of the failure. In such scenar
platform/x86/amd/pmc: Add dump_custom_stb module parameter
There have been instances when the default size (1M) of the STB is not sufficient to get the complete traces of the failure. In such scenarios we can use a module_param to enable full trace that shall contain more debugging data. This is not a regular case and hence not enabling this capability by default.
With this change, there will be two cases on how the driver fetches the stb data: 1) A special case (proposed now) - which is required only for certain platforms. Here, a new module param will be supplied to the driver that will have a special PMFW supporting enhanced dram sizes for getting the stb data. Without the special PMFW support, just setting the module param will not help to get the enhanced stb data.
To adapt to this change, we will have a new amd_pmc_stb_handle_efr() to handle enhanced firmware reporting mechanism. Note that, since num_samples based r/w pointer offset calculation is not required for enhanced firmware reporting we will have this mailbox command sent only in case of regular STB cases.
2) Current code branch which fetches the stb data based on the parameters like the num_samples, fsize and the r/w pointer.
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Co-developed-by: Harsh Jain <Harsh.Jain@amd.com> Signed-off-by: Harsh Jain <Harsh.Jain@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20231010145003.139932-3-Shyam-sundar.S-k@amd.com [ij: Renamed flex_arr -> stb_data_arr] Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| b1362257 | 10-Oct-2023 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
platform/x86/amd/pmc: Handle overflow cases where the num_samples range is higher
In amd_pmc_stb_debugfs_open_v2(), the stb buffer is created based on the num_samples and the read/write pointer offs
platform/x86/amd/pmc: Handle overflow cases where the num_samples range is higher
In amd_pmc_stb_debugfs_open_v2(), the stb buffer is created based on the num_samples and the read/write pointer offset. This holds good when the num_samples reported by PMFW is less than S2D_TELEMETRY_BYTES_MAX; where the stb buffer gets filled from 0th position until S2D_TELEMETRY_BYTES_MAX - 1 based on the read/write pointer offset.
But when the num_samples exceeds the S2D_TELEMETRY_BYTES_MAX, the current code does not handle it well as it does not account for the cases where the stb buffer has to filled up as a circular buffer.
Handle this scenario into two cases, where first memcpy will have the samples from location: (num_samples % S2D_TELEMETRY_BYTES_MAX) - (S2D_TELEMETRY_BYTES_MAX - 1) and next memcpy will have the newest ones i.e. 0 - (num_samples % S2D_TELEMETRY_BYTES_MAX - 1)
Suggested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20231010145003.139932-2-Shyam-sundar.S-k@amd.com [ij: renamed flex_arr -> stb_data_arr] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|