Skip to content
Snippets Groups Projects
  1. Nov 05, 2021
  2. Nov 03, 2021
  3. Oct 30, 2021
    • Sudeep Holla's avatar
      mailbox: pcc: Use PCC mailbox channel pointer instead of standard · 7b6da7fe
      Sudeep Holla authored
      
      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: default avatarSudeep Holla <sudeep.holla@arm.com>
      Acked-by: default avatarWolfram Sang <wsa@kernel.org>
      Acked-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      7b6da7fe
    • Sudeep Holla's avatar
      mailbox: pcc: Add pcc_mbox_chan structure to hold shared memory region info · 0f2591e2
      Sudeep Holla authored
      
      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: default avatarCristian Marussi <cristian.marussi@arm.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      0f2591e2
  4. Oct 27, 2021
  5. Oct 07, 2021
    • Miguel Bernal Marin's avatar
      ACPI: tools: fix compilation error · 136f2820
      Miguel Bernal Marin authored
      
      When ACPI tools are compiled, the following error is showed:
      
         $ cd tools/power/acpi
         $ make
           DESCEND tools/acpidbg
           MKDIR    include
           CP       include
           CC       tools/acpidbg/acpidbg.o
         In file included from /home/linux/tools/power/acpi/include/acpi/platform/acenv.h:152,
                          from /home/linux/tools/power/acpi/include/acpi/acpi.h:22,
                          from acpidbg.c:9:
         /home/linux/tools/power/acpi/include/acpi/platform/acgcc.h:25:10: fatal error: linux/stdarg.h: No such file or directory
            29 | #include <linux/stdarg.h>
               |          ^~~~~~~~~~~~~~~~
         compilation terminated.
      
      Use the ACPICA logic: just identify when it is used inside the kernel
      or by an ACPI tool.
      
      Fixes: c0891ac1 ("isystem: ship and use stdarg.h")
      Signed-off-by: default avatarMiguel Bernal Marin <miguel.bernal.marin@linux.intel.com>
      [ rjw: Changelog edits ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      136f2820
  6. Oct 05, 2021
  7. Sep 27, 2021
  8. Sep 23, 2021
    • Jia He's avatar
      Revert "ACPI: Add memory semantics to acpi_os_map_memory()" · 12064c17
      Jia He authored
      
      This reverts commit 437b38c5.
      
      The memory semantics added in commit 437b38c5 causes SystemMemory
      Operation region, whose address range is not described in the EFI memory
      map to be mapped as NormalNC memory on arm64 platforms (through
      acpi_os_map_memory() in acpi_ex_system_memory_space_handler()).
      
      This triggers the following abort on an ARM64 Ampere eMAG machine,
      because presumably the physical address range area backing the Opregion
      does not support NormalNC memory attributes driven on the bus.
      
       Internal error: synchronous external abort: 96000410 [#1] SMP
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
       Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
       pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [...snip...]
       Call trace:
        acpi_ex_system_memory_space_handler+0x26c/0x2c8
        acpi_ev_address_space_dispatch+0x228/0x2c4
        acpi_ex_access_region+0x114/0x268
        acpi_ex_field_datum_io+0x128/0x1b8
        acpi_ex_extract_from_field+0x14c/0x2ac
        acpi_ex_read_data_from_field+0x190/0x1b8
        acpi_ex_resolve_node_to_value+0x1ec/0x288
        acpi_ex_resolve_to_value+0x250/0x274
        acpi_ds_evaluate_name_path+0xac/0x124
        acpi_ds_exec_end_op+0x90/0x410
        acpi_ps_parse_loop+0x4ac/0x5d8
        acpi_ps_parse_aml+0xe0/0x2c8
        acpi_ps_execute_method+0x19c/0x1ac
        acpi_ns_evaluate+0x1f8/0x26c
        acpi_ns_init_one_device+0x104/0x140
        acpi_ns_walk_namespace+0x158/0x1d0
        acpi_ns_initialize_devices+0x194/0x218
        acpi_initialize_objects+0x48/0x50
        acpi_init+0xe0/0x498
      
      If the Opregion address range is not present in the EFI memory map there
      is no way for us to determine the memory attributes to use to map it -
      defaulting to NormalNC does not work (and it is not correct on a memory
      region that may have read side-effects) and therefore commit
      437b38c5 should be reverted, which means reverting back to the
      original behavior whereby address ranges that are mapped using
      acpi_os_map_memory() default to the safe devicenGnRnE attributes on
      ARM64 if the mapped address range is not defined in the EFI memory map.
      
      Fixes: 437b38c5 ("ACPI: Add memory semantics to acpi_os_map_memory()")
      Signed-off-by: default avatarJia He <justin.he@arm.com>
      Acked-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      12064c17
  9. Sep 13, 2021
  10. Sep 07, 2021
    • Rafael J. Wysocki's avatar
      ACPI: CPPC: Introduce cppc_get_nominal_perf() · 0654cf05
      Rafael J. Wysocki authored
      
      On some systems the nominal_perf value retrieved via CPPC is just
      a constant and fetching it doesn't require accessing any registers,
      so if it is the only CPPC capability that's needed, it is wasteful
      to run cppc_get_perf_caps() in order to get just that value alone,
      especially when this is done for CPUs other than the one running
      the code.
      
      For this reason, introduce cppc_get_nominal_perf() allowing
      nominal_perf to be obtained individually, by generalizing the
      existing cppc_get_desired_perf() (and renaming it) so it can be
      used to retrieve any specific CPPC capability value.
      
      While at it, clean up the cppc_get_desired_perf() kerneldoc comment
      a bit.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0654cf05
  11. Aug 25, 2021
  12. Aug 19, 2021
  13. Aug 16, 2021
  14. Jul 24, 2021
  15. Jul 19, 2021
  16. Jun 25, 2021
  17. Jun 17, 2021
  18. Jun 10, 2021
  19. Jun 07, 2021
Loading