Skip to content
Snippets Groups Projects
Select Git revision
7 results
Search by author
  • Any Author
  •     lukas
  • Aaron Watry Aaron Watry awatry
  • Abhinav Kumar Abhinav Kumar abhinavk
  • Adam Jackson Adam Jackson ajax
  • Aditya Swarup Aditya Swarup aswarup
  • Alain Volmat Alain Volmat avolmat-stm
  • Alejandro Piñeiro Alejandro Piñeiro apinheiro
  • Alexander von Gluck Alexander von Gluck kallisti5
  • Alexandru Gheorghe Alexandru Gheorghe alex_g1
  • Alex Deucher Alex Deucher agd5f
  • Alex Lanzano Alex Lanzano alexlanzano
  • Alex Smith Alex Smith aejsmith
  • Alok Hota Alok Hota ahota
  • Alyssa Rosenzweig Alyssa Rosenzweig alyssa
  • André Almeida André Almeida andrealmeid
  • Andreas Baierl Andreas Baierl rellla
  • Andreas Boll Andreas Boll ab
  • Andres Gomez Andres Gomez tanty
  • Andres Rodriguez Andres Rodriguez lostgoat
  • Andrey Grodzovsky Andrey Grodzovsky agrodzov
20 authors
  1. Dec 10, 2024
  3. Nov 29, 2024
  5. Nov 27, 2024
    • Chen-Yu Tsai's avatar
      i2c: Introduce OF component probe function · 157ce8f3
      Chen-Yu Tsai authored 
      
Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.

This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.

Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component probe function. For a
given class of devices on the same I2C bus, it will go through all of
them, doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.

This requires some minor modifications in the existing device tree. The
status for all the device nodes for the component options must be set
to "fail-needs-probe". This makes it clear that some mechanism is
needed to enable one of them, and also prevents the prober and device
drivers running at the same time.

Signed-off-by: default avatarChen-Yu Tsai <wenst@chromium.org>
Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      157ce8f3
    • Rong Xu's avatar
      kbuild: Add Propeller configuration for kernel build · d5dc9583
      Rong Xu authored 
      Add the build support for using Clang's Propeller optimizer. Like
AutoFDO, Propeller uses hardware sampling to gather information
about the frequency of execution of different code paths within a
binary. This information is then used to guide the compiler's
optimization decisions, resulting in a more efficient binary.

The support requires a Clang compiler LLVM 19 or later, and the
create_llvm_prof tool
(https://github.com/google/autofdo/releases/tag/v0.30.1). This
commit is limited to x86 platforms that support PMU features
like LBR on Intel machines and AMD Zen3 BRS.

Here is an example workflow for building an AutoFDO+Propeller
optimized kernel:

1) Build the kernel on the host machine, with AutoFDO and Propeller
   build config
      CONFIG_AUTOFDO_CLANG=y
      CONFIG_PROPELLER_CLANG=y
   then
      $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<autofdo_profile>

“<autofdo_profile>” is the profile collected when doing a non-Propeller
AutoFDO build. This step builds a kernel that has the same optimization
level as AutoFDO, plus a metadata section that records basic block
information. This kernel image runs as fast as an AutoFDO optimized
kernel.

2) Install the kernel on test/production machines.

3) Run the load tests. The '-c' option in perf specifies the sample
   event period. We suggest using a suitable prime number,
   like 500009, for this purpose.
   For Intel platforms:
      $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> \
        -o <perf_file> -- <loadtest>
   For AMD platforms:
      The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2
      # To see if Zen3 support LBR:
      $ cat proc/cpuinfo | grep " brs"
      # To see if Zen4 support LBR:
      $ cat proc/cpuinfo | grep amd_lbr_v2
      # If the result is yes, then collect the profile using:
      $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \
        -N -b -c <count> -o <perf_file> -- <loadtest>

4) (Optional) Download the raw perf file to the host machine.

5) Generate Propeller profile:
   $ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> \
     --format=propeller --propeller_output_module_name \
     --out=<propeller_profile_prefix>_cc_profile.txt \
     --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt

   “create_llvm_prof” is the profile conversion tool, and a prebuilt
   binary for linux can be found on
   https://github.com/google/autofdo/releases/tag/v0.30.1

 (can also build
   from source).

   "<propeller_profile_prefix>" can be something like
   "/home/user/dir/any_string".

   This command generates a pair of Propeller profiles:
   "<propeller_profile_prefix>_cc_profile.txt" and
   "<propeller_profile_prefix>_ld_profile.txt".

6) Rebuild the kernel using the AutoFDO and Propeller profile files.
      CONFIG_AUTOFDO_CLANG=y
      CONFIG_PROPELLER_CLANG=y
   and
      $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<autofdo_profile> \
        CLANG_PROPELLER_PROFILE_PREFIX=<propeller_profile_prefix>

Co-developed-by: default avatarHan Shen <shenhan@google.com>
Signed-off-by: default avatarHan Shen <shenhan@google.com>
Signed-off-by: default avatarRong Xu <xur@google.com>
Suggested-by: default avatarSriraman Tallam <tmsriram@google.com>
Suggested-by: default avatarKrzysztof Pszeniczny <kpszeniczny@google.com>
Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
Suggested-by: default avatarStephane Eranian <eranian@google.com>
Tested-by: default avatarYonghong Song <yonghong.song@linux.dev>
Tested-by: default avatarNathan Chancellor <nathan@kernel.org>
Reviewed-by: default avatarKees Cook <kees@kernel.org>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      d5dc9583
  7. Nov 24, 2024
  9. Nov 21, 2024
  11. Nov 19, 2024
  13. Nov 18, 2024
  15. Nov 17, 2024
  17. Nov 16, 2024
  19. Nov 15, 2024
  21. Nov 14, 2024
  23. Nov 13, 2024
  25. Nov 12, 2024