User:Knuxify/Draft:Qualcomm/Adding a new SoC to mainline Linux: Difference between revisions

Knuxify (talk | contribs)
Created page with "{{Subpage of|Qualcomm}} {{Work-in-progress page|note=Currently in the middle of finding this out in real time :)}} This guide will cover the process of adding support for a recent (~2020 or newer, todo?) Qualcomm SoC into mainline Linux. Most of the information contained within is also applicable to older chips, though more manual effort may be needed to get these to run. <!--For the U-Boot guide, see TODO.--> == High-level overview == {{todo|Some of this will have to..."
 
Knuxify (talk | contribs)
No edit summary
Line 3: Line 3:


This guide will cover the process of adding support for a recent (~2020 or newer, todo?) Qualcomm SoC into mainline Linux. Most of the information contained within is also applicable to older chips, though more manual effort may be needed to get these to run. <!--For the U-Boot guide, see TODO.-->
This guide will cover the process of adding support for a recent (~2020 or newer, todo?) Qualcomm SoC into mainline Linux. Most of the information contained within is also applicable to older chips, though more manual effort may be needed to get these to run. <!--For the U-Boot guide, see TODO.-->
This guide was tested with the SM7435. Some details might be different for other SoCs. If you have any hints, please contribute!


== High-level overview ==
== High-level overview ==
Line 36: Line 38:
* A copy of the downstream kernel; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by codename).
* A copy of the downstream kernel; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by codename).
* A copy of the <code>qcom_proprietary_devicetree</code> or similar repo with the DTSI source files (because they're not in the kernel repo for whatever reason...). Search for <code>(codename).dtsi</code> on GitHub and you'll find the right repository eventually.
* A copy of the <code>qcom_proprietary_devicetree</code> or similar repo with the DTSI source files (because they're not in the kernel repo for whatever reason...). Search for <code>(codename).dtsi</code> on GitHub and you'll find the right repository eventually.
* An extracted DTB from your device. Dump this from a running device using FDT
* An extracted DTB from your device. Dump this from a running device using FDT (todo: instructions, would probably be good on a generic page, maybe subpage of [[Devicetree]]?
* Find a similar SoC that is already supported. Usually flagship SoCs are available in mainline; try to find a flagship from around the same time as the SoC you're mainlining. Find its DTSIs as well; then you can compare the differences between downstream and mainline for the upstreamed SoC, and correlate them with differences in your SoC.
 
== Adding the DTSI ==
 
todo


== Porting individual parts ==
== Porting individual parts ==
Line 43: Line 50:


On recent Qualcomm SoCs, the downstream kernel uses the mainline Qualcomm clock driver with only ''some'' vendor-specific quirks. This means that the clock drivers and their relevant headers can pretty much be copied verbatim from downstream, with some slight modifications.
On recent Qualcomm SoCs, the downstream kernel uses the mainline Qualcomm clock driver with only ''some'' vendor-specific quirks. This means that the clock drivers and their relevant headers can pretty much be copied verbatim from downstream, with some slight modifications.
First, create the '''GCC''' driver. Open <code>driver/clk/qcom/Kconfig</code> and add the relevant Kconfig option for your SoC (remember to keep it ordered alphabetically):
<syntaxhighlight lang="kconfig">
config SM_GCC_xxxx
tristate "SMxxxx Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
help
  Support for the global clock controller on SMxxxx devices.
  Say Y if you want to use peripheral devices such as UART,
  SPI, I2C, USB, SD/UFS, PCIe etc.
</syntaxhighlight>
Open <code>driver/clk/qcom/Makefile</code> and add the relevant entry:
<syntaxhighlight lang="makefile">
obj-$(CONFIG_SM_GCC_xxxx) += gcc-smXXXX.o
</syntaxhighlight>
Open <code>driver/clk/qcom/gcc-smXXXX.c</code>.
Paste the initialization code from another GCC driver (<syntaxhighlight inline lang="c">static struct platform_driver gcc_smXXXX_driver</syntaxhighlight> and onwards.)
== Porting the PMIC(s) ==
Qualcomm devices use ''multiple'' PMICs for different purposes. Often, the PMIC is paired with an SoC or series of SoCs.