Mainlining Wiki

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

← Older edit
VisualWikitext
Knuxify (talk | contribs)
103 edits
Knuxify (talk | contribs)
103 edits
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 2: Line 2:
{{Work-in-progress page|note=Currently in the middle of finding this out in real time :)}}
{{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.-->
This guide will cover the process of adding support for a recent (~2020 or newer) Qualcomm SoC into mainline Linux. <!--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!
This guide was tested with the SM7435. Some details might be different for other SoCs. If you have any hints, please contribute!
Line 48: Line 48:
todo
todo


== Porting individual parts ==
== Clock controllers ==


=== Clock controllers ===
{{note|'''A note about licences and copying code:''' a good chunk of drivers can be copied from downstream with minimal modifications. In those cases, keep the original copyright at the top of the file ''(Copyright (c) 20xx, Qualcomm Innovation Center, Inc. etc)'', and add yourself below. (This seems to be how it was done for milos as well.)}}


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 ''some'' vendor-specific quirks. This means that the clock drivers and their relevant headers can pretty much be copied verbatim from downstream, though quite a few modifications are needed.


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):
All clock controllers (gcc, dispcc, gpucc, videocc, camcc) use the same clock framework, so the following steps will work for all of them.
 
{{hint|Start with '''GCC''', as it's needed for most components. You may also need '''DISPCC''' for the display/framebuffer. Then do the remaining ones (GPUCC, VIDEOCC, CAMCC).}}
 
==== Creating the driver ====
 
First, create the 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">
<syntaxhighlight lang="kconfig">
config SM_GCC_xxxx
config SM_GCC_xxxx
tristate "SMxxxx Global Clock Controller"
tristate "xxxx Global Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
select QCOM_GDSC
help
help
  Support for the global clock controller on SMxxxx devices.
  Support for the global clock controller on xxxx devices.
  Say Y if you want to use peripheral devices such as UART,
  Say Y if you want to use peripheral devices such as UART,
  SPI, I2C, USB, SD/UFS, PCIe etc.
  SPI, I2C, USB, SD/UFS, PCIe etc.
Line 73: Line 79:
</syntaxhighlight>
</syntaxhighlight>


Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>.
Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>; also copy the dt-bindings from <code>include/dt-bindings/clock/qcom,gcc-CODENAME.h</code> to <code>include/dt-bindings/clock/qcom,CODENAME-gcc.h</code> in mainline.
 
=== Simple changes ===
 
* <code>&lt;linux/platform_device.h&gt;</code> needs to be added to includes
* Anywhere <code>enable_safe_config</code> is set to <code>true</code>, remove it and change ops to <code>clk_rcg2_shared_ops</code><ref>https://lore.kernel.org/all/YbJMnvg%2FIDwHNeWS@ripper/</ref>.
* <code>CLK_DONT_HOLD_STATE</code> in clock flags is downstream-specific, it has no equivalent in mainline.
 
=== Clock VDDs/regulators ===
 
Remove anything related to "clock VDDs/regulators":
 
* The <code>"vdd-level.h"</code> include,
* The regulator defines at the top,
* <code>.clkr.vdd_data</code> members in clk data structs,
* regulator_data in final desc struct.
 
These have no mainline equivalent.
 
=== Clock parent data ===
 
Downstream and mainline differ in two significant ways when it comes to how clock parents are defined:
 
* Downstream uses clock names; mainline uses '''clock IDs''' according to an enum at the start of the driver that is meant to be in the same order as the DT IDs.
* Downstream puts the parent data directly in the clock struct; mainline puts it in separate structs.
 
=== Probe ===
 
The way probing is done is different in mainline.
 
Look at the probe function, and find the following components:


Paste the initialization code from another GCC driver (<syntaxhighlight inline lang="c">static struct platform_driver gcc_smXXXX_driver</syntaxhighlight> and onwards.)
* Calls to <code>clk_lucid_evo_pll_configure</code>: note down the "&disp_cc_pllX" pointers, and place them in a struct: <syntaxhighlight lang="c">static struct clk_alpha_pll *disp_cc_CODENAME_plls[] = {
&disp_cc_pll0,
};</syntaxhighlight>
* <code>regmap_update_bits</code> calls prefaced by a comment saying "Keep clocks always enabled": note down the 0x... addresses and place them in a struct like so: <syntaxhighlight lang="c">static u32 disp_cc_CODENAME_critical_cbcrs[] = {
0xe054, /* DISP_CC_XO_CLK */
};</syntaxhighlight>
* Remaining <code>regmap_update_bits</code> calls: keep them, with the comments intact, and move them into a new function: <syntaxhighlight lang="c">static void disp_cc_CODENAME_clk_regs_configure(struct device *dev, struct regmap *regmap)
{
/* Enable clock gating for MDP clocks */
regmap_update_bits(regmap, DISP_CC_MISC_CMD, 0x10, 0x10);
}</syntaxhighlight>
* Then, add the driver_data struct: <syntaxhighlight lang="c">static struct qcom_cc_driver_data disp_cc_CODENAME_driver_data = {
.alpha_plls = disp_cc_CODENAME_plls,
.num_alpha_plls = ARRAY_SIZE(disp_cc_CODENAME_plls),
.clk_cbcrs = disp_cc_CODENAME_critical_cbcrs,
.num_clk_cbcrs = ARRAY_SIZE(disp_cc_CODENAME_critical_cbcrs),
.clk_regs_configure = disp_cc_CODENAME_clk_regs_configure,
};</syntaxhighlight>


{{todo|There are some missing struct members, these can be ommited. IIRC one has a counterpart in mainline but I don't remember which one... revisit this, maybe?}}
For the rest of the probe steps, see how other drivers do it.


=== Interconnect driver ===
== Interconnect driver ==


TODO figure out what the interconnect actually does.
{{todo|figure out what the interconnect actually does.}}


Similar to clocks, interconnects are nearly the same as in downstream, but need some changes.
Similar to clocks, interconnects are nearly the same as in downstream, but need some changes.
Line 95: Line 148:
''See https://lore.kernel.org/all/[email protected]/ for an example. Ignore the part where they add <code>alloc_dyn_id</code>, that was removed in another commit as dynamic IDs are now the only option.''
''See https://lore.kernel.org/all/[email protected]/ for an example. Ignore the part where they add <code>alloc_dyn_id</code>, that was removed in another commit as dynamic IDs are now the only option.''


=== TLMM/pinctrl ===
== TLMM/pinctrl ==


Driver is in drivers/pinctrl/qcom.
Driver is in drivers/pinctrl/qcom.
Retrieved from "https://wiki.mainlining.org/wiki/User:Knuxify/Draft:Qualcomm/Adding_a_new_SoC_to_mainline_Linux"