Hello Brian,
On Wed, Oct 27, 2021 at 3:24 PM Brian Hutchinson <b.hutchman@...> wrote:
Hi Andrey,
On Wed, Oct 27, 2021 at 9:01 AM Andrey Zhizhikin <andrey.z@...> wrote:
Hello Brian,
On Wed, Oct 27, 2021 at 2:45 PM Brian Hutchinson <b.hutchman@...> wrote:
On Wed, Oct 27, 2021 at 8:18 AM Fabio Estevam <festevam@...> wrote:
Hi Brian,
On Tue, Oct 26, 2021 at 11:10 AM Brian Hutchinson <b.hutchman@...> wrote:
On Tue, Oct 26, 2021 at 10:07 AM Brian Hutchinson via lists.yoctoproject.org <b.hutchman=gmail.com@...> wrote:
Hi,
First, forgive me for posting a link in an post with no context ... I hit a wrong button and accidentally sent before ready.
Bottom line up front. How can I get a 5.10 kernel with multi-lane support for IMX8MM?
We use linux-fsl 5.4 on a IMXMM based board and have recently stepped up to linux-fsl 5.10 and the sound/fsl/fsl_sai.c has no support for "multi-lane" anymore which breaks our code.
I figure this is simply a case where things in linux-imx are new and just not picked up in linux-fslc yet but wondering if it's possible to get multi-lane support in a 5.10 kernel for the IMX8MM.
I still don't quite fully understand how all the releases work, the linux-imx releases appear to be for newer boards and don't necessarily support the older boards from what I'm seeing.
Thanks for any advice/guidance.
Regards,
Brian
And that link I accidentally posted by itself https://source.codeaurora.org/external/imx/linux-imx/tree/sound/soc/fsl/fsl_sai.c?h=lf-5.10.y
... is the reference I mentioned where I see multi-lane support in linux-imx 5.10.
With the mainline SAI driver, it is possible to use several channels.
Not sure what you mean by "multi-lane" in your use-case.
Please check:
https://bootlin.com/blog/eight-channels-audio-on-i-mx7-with-pcm3168/
I hoped folks would know what I was talking about without getting too far into the weeds. But I guess I need to explain more.
The older 5.4 kernels (and even 4 series kernels) had a imx8mm-evk.dts sai section that looked like this:
&sai1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sai1>;
assigned-clocks = <&clk IMX8MM_CLK_SAI1>;
assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
assigned-clock-rates = <24576000>;
clocks = <&clk IMX8MM_CLK_SAI1_IPG>, <&clk IMX8MM_CLK_DUMMY>,
<&clk IMX8MM_CLK_SAI1_ROOT>, <&clk IMX8MM_CLK_DUMMY>,
<&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_AUDIO_PLL1_OUT>,
<&clk IMX8MM_AUDIO_PLL2_OUT>;
clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
fsl,sai-multi-lane;
fsl,dataline,dsd = <0 0xff 0xff 2 0xff 0x11>;
fsl,sai-synchronous-rx;
dmas = <&sdma2 0 25 0>, <&sdma2 1 25 0>;
#sound-dai-cells = <0>;
status = "okay";
};
... which has fsl,sai-multi-lane support.
The current linux-fslc 5.10 kernel does not have fsl,sai-multi-lane support.
linux-fslc-imx kernel recipe on the [master] branch on meta-freescale
provides a kernel, which has linux-imx as a base and latest LTS
applied on top.
Assuming you're building now off the [master] branch and do not set
the IMX_DEFAULT_BSP to any value anywhere in your conf files - you
will be building a Mainline BSP (see [1]), which does select
linux-fslc as a preferred provider for your kernel, see [2].
You can try to either switch your BSP to NXP one by setting
IMX_DEFAULT_BSP = "nxp", or switch your kernel provider to
"linux-fslc-imx" one.
I really would like to stick with linux-fslc since that's what we've been using for more than a year now. Kind of scared to switch back to linux-fslc-imx (I'll try to do better with my terminology) but if you guys think that's best then I'll try it. Worried that our custom apps might be impacted by the switch.
As a quick GIT grep in the linux-fslc repo on [5.10-2.1.x-imx] branch:
git grep sai-multi-lane
arch/arm64/boot/dts/freescale/imx8mm-evk-ak4497.dts: fsl,sai-multi-lane;
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi: fsl,sai-multi-lane;
arch/arm64/boot/dts/freescale/imx8mp-ab2.dts: fsl,sai-multi-lane;
arch/arm64/boot/dts/freescale/imx8mq-evk-ak4497.dts: fsl,sai-multi-lane;
arch/arm64/boot/dts/freescale/imx8mq-evk.dts: fsl,sai-multi-lane;
sound/soc/fsl/fsl_sai.c: if (of_find_property(np,
"fsl,sai-multi-lane", NULL))
Guess this is what you're looking for, right?
I'd be ok with doing a build of just the kernel on master branch as long as it supports imx8mm-evk (what our board is based on) but the rest of our rootfs is based on Dunfell release.
So if I'm following you correctly, you're saying the linux-fslc repo has imx 5.10 with multi-lane in it.
There are 2 kernel repositories here at play, namely:
- linux-fslc from Freescale GitHub
- linux-imx from CodeAurora
They both stem from stable korg, but using different strategy to evolve.
linux-imx is an NXP kernel fork, which they use to commit their
internal patches on top of some stable release. In case of 5.10 - it
is v5.10.54 from stable korg, which resides on [lf-5.10.y] branch.
linux-fslc is combination of various branches, and if we look at the
5.10 - there is a corresponding branch [5.10.x+fslc], and it is
practically a vanilla 5.10.y kernel from stable korg, with only
handful of patches on top.
If I to examine this like that:
$ git log --oneline --no-merges stable/linux-5.10.y..5.10.x+fslc | wc -l
9
As one can see, it has only 9 patches on top of stable korg.
What comes in addition inside linux-fslc repository, is the branch
[5.10-2.1.x-imx], which is a combination of [lf-5.10.y] branch from
linux-imx repo and latest stable patch applied on top of it (with
merge conflict resolution, of course).
When examined, it brings the following:
$ git log --oneline --no-merges stable/linux-5.10.y..5.10-2.1.x-imx | wc -l
5456
Here we see, that there is a substantial difference in terms of number
of patches applied. It might be a new functionality (like your desired
multi-lane support), but can also contain a code in question, which
might not work for all scenarios you're applying your kernel to.
Hope that clears it a bit, and would help you to drive your decision
further on which kernel to use.
How come linux-fslc 5.10 doesn't have it? Is it a case where imx released it later and hasn't worked it's way into linux-fslc yet?
That is the trick: you most probably used the NXP-based up-merged
branch in your BSP, but now when switched to new Yocto release - you
received a vanilla kernel, which does not have those NXP patches
applied.
I'd be willing to "try" 5.10.2.1.x-imx just to see if it solves our problem but still would prefer to stick with linux-fslc ... but if that's the only way to get this feature back I guess I'll have to do what I need to do.
I still get confused by linux-fslc, linux-imx linux-fslc-imx some. Which one would be the safest (aka most stable) for imx8mm ... and have multi-lane support?
Thanks again for putting up with my dumb questions and weird issues. Everything was ok until we had to step up to 5.4 in order to pick up some DSA PTP (1588) patches.
Regards,
Brian
--
Regards,
Andrey.
