On Thu 16 Dec 2021 at 14:07, qianggui.song [off-list ref] wrote:
quoted
quoted
+static const unsigned int clk12_24_pins[] = { GPIOD_10 };
+static const unsigned int pwm_g_hiz_pins[] = { GPIOD_11 };
+
[...]
quoted
+
+static const char * const tdm_groups[] = {
+ "tdm_d2_c", "tdm_d3_c", "tdm_fs1_c", "tdm_d4_c", "tdm_d5_c",
+ "tdm_fs1_d", "tdm_d4_d", "tdm_d3_d", "tdm_d2_d", "tdm_sclk1_d",
+ "tdm_sclk1_h", "tdm_fs1_h", "tdm_d2_h", "tdm_d3_h", "tdm_d4_h",
+ "tdm_d1", "tdm_d0", "tdm_fs0", "tdm_sclk0", "tdm_fs2", "tdm_sclk2",
+ "tdm_d4_z", "tdm_d5_z", "tdm_d6", "tdm_d7"
+};
On previous chip, there were pin assigned to tdm A, B or C.
On this generation, it seems you have added a second level on pinmuxing
to re-route the audio pins to different controllers
In such case, I don't think they belong in the same group.
Depending on settins, D2 and D3 could be unrelated
I think each audio pin should have its own group (one group for D3, one
D4, etc ...)
According to our audio colleague, on this chip, tdm A/B/C can choose which
pins are routed to their controllers freely by writing special registers,
say, tdm_d2_c can be assigned to any of tdm a, b and c by demand, so no
need to specify a/b/c words any more.
That's basically my comment above. Comment still stands
Each D and FS pin could be related to different interface and should be
in different groups
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel