[Linux Audio Driver] SM6350平台音频bring up ( 一 )

0. 背景

这个是高通5G平台，音频的内容改的比较多，比较直接的是platform.c就直接移动到vendor了；目前
高通那边的趋势还是把音频逐渐从kernel剥离，android 7/android 8的时候，machine driver，codec driver都在kernel；android 9、android 10之后machine driver，codec driver都移动到了vendor；

到这个5G平台的时候，platform.c以及XML都移到vendor里面去了。 最近准备写几篇从零开始bring up
音频的文档，但是更新不会很快。（最近比较没时间）这一篇主要是讲的是：
确定音频走的设备树。

#更新2021.07.13
这里更新下，我后来发现更新的android11的基线，machine driver又被移到 kernel了。。。
#更新2021.07.13

1. 检索machine

先抓一份开机log，原则上音频的调试开始，需要保证modem没有问题，adsp正确加载，然后kernel
可以跑起来，android 进不去其实没关系。因为可以用tinyalsa验证功能。

App Log Flush : 23 ms
Exit EBS        [13291] UEFI End
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x51df805e]
[    0.000000] Linux version 4.19.81 (Data.BU@Meig.China) 
(clang version 8.0.12 for Android NDK) #1 SMP PREEMPT Sat Aug 29 01:49:13 CST 2020
[    0.000000] Machine model: Qualcomm Technologies, Inc. Lagoon MTP
[    0.000000] earlycon: msm_geni_serial0 at MMIO 0x000000000098c000 (options '')
[    0.000000] bootconsole [msm_geni_serial0] enabled
[    0.000000] efi: Getting EFI parameters from FDT:

检索machine之后，我们可以得到重要信息：Machine model: Qualcomm Technologies, Inc. Lagoon MTP，然后检索这个log。（为啥上来确定这个log在vendor里面检索呢，一是可以直接搜所有代码，
二是从高通提供的大量文档，可以了解到设备树在vendor，音频核心的一些API其实还是在kernel)

grep -nr "Qualcomm Technologies, Inc. Lagoon MTP" ./vendor/qcom/proprietary/devicetree-4.19

返回的log如下，但是我们期望的dts肯定不是：lagoon-mtp-usbc.dts和lagoon-mtp-usbc-overlay.dts，原因是我们开机检索machine是不带usbc后缀的；

#更新2020.12.01
<
这个打印的调用关系如下：
./kernel/msm-4.19/drivers/of/fdt.c

const void * __init of_flat_dt_match_machine(const void *default_match,
          const void * (*get_next_compat)(const char * const**))
  {
      const void *data = NULL;
      const void *best_data = default_match;
      const char *const *compat;
      unsigned long dt_root;
      unsigned int best_score = ~1, score = 0;
 
      dt_root = of_get_flat_dt_root();
      while ((data = get_next_compat(&compat))) {
          score = of_flat_dt_match(dt_root, compat);
          if (score > 0 && score < best_score) {
              best_data = data;
              best_score = score;
          }
      }
      if (!best_data) {
          const char *prop;
          int size;
 
          pr_err("\n unrecognized device tree list:\n[ ");
 
          prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
          if (prop) {
              while (size > 0) {
                  printk("'%s' ", prop);
                  size -= strlen(prop) + 1;
                  prop += strlen(prop) + 1;
              }
          }
          printk("]\n\n");
          return NULL;
      }
 
      pr_info("Machine model: %s\n", of_flat_dt_get_machine_name());
 
      return best_data;
  }

然后调用：of_flat_dt_get_machine_name函数，

 const char * __init of_flat_dt_get_machine_name(void)
 {
     const char *name;
     unsigned long dt_root = of_get_flat_dt_root();
 
     name = of_get_flat_dt_prop(dt_root, "model", NULL);
     if (!name)
         name = of_get_flat_dt_prop(dt_root, "compatible", NULL);
     return name;
 }

of_get_flat_dt_prop函数会获取到dts里面定义的model后面的字符串，然后把它打印出来。

#更新2020.12.01

2. 查看makefile

还剩下两个dts不晓得用哪个，我们进入这些dts下面的makefile看下；

vim ./vendor/qcom/proprietary/devicetree-4.19/qcom/Makefile

很明显，我们只需要看lagoon前缀的，

makefile里面有个宏，我们需要查下：

grep -nr "CONFIG_BUILD_ARM64_DT_OVERLAY" ./

看到这个kernel以及qssi，qssi直接拉高通代码编译，会在out目录有这个文件夹，具体干嘛的俺还不知道，但是可以明确这个CONFIG_BUILD_ARM64_DT_OVERLAY被设置成了y。

从编译生成的dtb可以看出，这里采用lagoon.dtb以及lagoon加两个后缀的dtb，排除加一个后缀的dtb，
所以lagoon-mtp.dts被排除了，最终确定音频走的就是：lagoon-mtp-overlay.dts

#更新2020.12.01

由于CONFIG_BUILD_ARM64_DT_OVERLAY宏已经被定义，所以根据lagoon-mtp-overlay.dtbo-base := lagoon.dtb， 此处还可以确定lagoon.dts也会走，注意一般一套设备树会走两个dts。

#更新2020.12.01

3. 进一步确定

vim ./vendor/qcom/proprietary/devicetree-4.19/qcom/lagoon-mtp-overlay.dts

  #include <dt-bindings/interrupt-controller/arm-gic.h>
  #include "lagoon-mtp.dtsi"
  
  / {
       model = "Qualcomm Technologies, Inc. Lagoon MTP";
       compatible = "qcom,lagoon-mtp", "qcom,lagoon", "qcom,mtp";
       qcom,msm-id = <434 0x10000>, <459 0x10000>;
       qcom,board-id = <8 0>;
  };

vim进去看一下，发现了msm-id以及board-id。 再看下它包含的lagoon-mtp.dtsi，这里注意lagoon-mtp.dts被排除了，不代表 lagoon-mtp.dtsi也被排除了。 然后我们看看lagoon-mtp.dtsi，

这里从名字可以看到，音频还走lagoon-audio-overlay.dtsi，我们进去看看这个设备树的话，可以找到
大量的设备时钟、供电gpio，codec匹配的名字配置等等。一般来说都是平台相关的，尽量别乱改这个时钟，还有map的东西；常改的就是把不用的disabled，要用的加上status = “ok”，虽然默认不disabled的话，一般也是ok的，但是我还是习惯加上。

其他建议的地方就是注意，设备树复用，一些重要的修改，还是要多grep 一下，重复的删除，让代码简洁干净。（这个一般要参考高通文档）。

当前确定这三个肯定是走的：lagoon-mtp-overlay.dts、lagoon-mtp.dtsi、lagoon-audio-overlay.dtsi。这就是我们要找的音频设备树。当然也有其他的，就看他们还包含了哪些了。

4. 补充说明

这里需要补充说明下msm-id和board-id，msm-id是高通CPU里面的信息，不可修改(必须完全匹配)； board-id是从modem传过来的（遵从最佳匹配原则，而不是完全匹配）。

我们回到lagoon-mtp-overlay.dts，

vim ./vendor/qcom/proprietary/devicetree-4.19/qcom/lagoon-mtp-overlay.dts

回到modem，检索BP侧代码：

sm6350/bitra-la-1-0_amss_standard_oem$ find BOOT.XF.3.3/boot_images/ -name boot_cdt_array.c

BOOT.XF.3.3/boot_images/QcomPkg/SocPkg/Library/XBLLoaderLib/boot_cdt_array.c

（msm-id 图）

回到qcom,board-id = <8 0>; 这个是10进制的，换成16进制，应为<0x08 0x00>，0x00与modem那边的board id设置其实根本没有关系，它只匹配了0x08，但是依然能匹配上，这就是所谓的有限匹配的意思。

#更新2020.10.12
最后这里描述错误，上图中我们圈了四个16进制数字。

设备树里面的qcom,board-id = <8 0>; 8对应0x08，匹配了hardware id， 0对应0x00，匹配了sub id。
#更新2020.10.12

5. 作者注

/******
@article{Linux Audio Driver,
Author = { 1byte ≠ 8bit},
Year = { 2020},
}
******/