Re: [PATCH v7 1/5] ASoC: makes CPU/Codec channel connection map more generic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue 12 Mar 2024 at 17:06, Mark Brown <broonie@xxxxxxxxxx> wrote:

> [[PGP Signed Part:Undecided]]
> On Tue, Mar 12, 2024 at 05:29:25PM +0100, Jerome Brunet wrote:
>
>> Mark, I suspect the boards you have (like the libretech Alta/Solitude or
>> the kvim3 maybe) will show the same thing.
>
> I don't have the kvim3 but I can try with the other two (modulo pain
> with u-boot), it'll be tomorrow now though.

I've check the other boards from same SoC family (g12 and sm1) for the
same kernel build:

https://linux.kernelci.org/test/job/mainline/branch/master/kernel/v6.8-rc7-250-g137e0ec05aeb/plan/baseline/

* Only the u200 is failing. The others devices of the same family are fine.
* The u200 is the only one being test with gcc-10 / defconfig + debug
* The others have been tested with clang-16 / defconfig + CONFIG_ARM64_64K_PAGES

I've checked locally with gcc-13 on the vim3l (sm1 - s905x3)
* OK with defconfig
* Problem reproduced with defconfig + debug fragment from kCI - Observations:
  * Kernel is extremely fat (150+ MB)
  * Boot process incredibly slow.

Fragment is here:
https://storage.kernelci.org/mainline/master/v6.8-rc7-250-g137e0ec05aeb/arm64/defconfig+debug/gcc-10/config/kernelci.config

I'll continue to check but this is apparently related to the options
turned on by the debug fragment. Maybe it could be interesting to check
another non-intel SoC manufacturer using DPCM with this fragment ?
(another device relying on cleared ch_maps - Renesas and/or MTK maybe ?)

-- 
Jerome




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux