03:30 <mturquette> Hi rockosov ! the second approach is a safe one, at least for your first submission of this patch series. In your coverletter you should Cc Jian Hu and explain that you have carried the patches forward. Do not be surprised for a submaintainer to ask you to condense the patches to make it easier to review.

03:31 <mturquette> So basically start with Option 2, but be prepared to then go to Option 1. This is more of a formality to respect Jian Hu's work, and to avoid looking like you are "stealing" someone else's patches

03:31 <mturquette> these are just my opinions though. Others will have different ideas on the best way forward.

08:42 <rockosov> mturquette: Thank you for quick reply! It's clear for me now. Will wait any feedback from maintainers jbrunet, narmstrong and krzysztof in the LKML. I'm ready to rework my patch series to option 1 format, by IMHO I'm agree with you and Option 2 is a more honest approach to Jian Hu as first author of these patches.

08:45 <narmstrong> rockosov: yes you did right, we'll tell you if the patchset needs to be reorganised

08:45 <narmstrong> rockosov: I'm curious, what are the other changes you'll submit ?

09:10 <rockosov> narmstrong: What do you mean? If you are talking about other A113L drivers, we have some patch series internally. In the current moment we are adapting them for the upstreaming (kernel + uboot). Will send soon.

09:10 <narmstrong> rockosov: yep about A113L

09:10 <rockosov> narmstrong: I decided to start with CLK controller, because it's base for other peripherals.

09:12 <rockosov> narmstrong: BTW, if we already start such discussion :-) We don't understand uboot upstreaming process. Should we send patch series to meson custodian or to uboot mainline? Could you please advise if possible?

09:13 <narmstrong> rockosov: to uboot mainline with u-boot-amlogic@groups.io in CC, it works very like Linux, Custodians are the same as Linux maintainers trees

09:14 <rockosov> narmstrong: ah, got it, thanks a lot

09:14 <narmstrong> you have the same checkpatch, get_maintainers & review requirements

09:14 <narmstrong> but I'll be able to pick much more patches

09:15 <rockosov> narmstrong: perfect! These tools fix a lot of style problems, that's nice

10:15 <rockosov> narmstrong: About planned A113L changes which we want to submit.

10:15 <rockosov> I suppose the plan looks like:

10:15 <rockosov> * CPU clk controller + cpufreq/tsensor/voltage regulator/supply setup

10:15 <rockosov> * Audio card (clk, internal codec (playback + capture), resampler, SoC loopback, pdm, etc)

10:15 <rockosov> * efuse (small changes, current driver is applicable for A113L)

10:15 <rockosov> * SPICC/SPIFC support

10:15 <rockosov> * other misc peripherals small patches

10:19 <narmstrong> rockosov: nice, thx for your effort

10:59 <jbrunet> oops

11:11 <rockosov> jbrunet: Sure, we will prepare RFC patch first, no problem.

11:11 <rockosov> Fully agree with you about Auge HW audio card complexity. And yes, resampler HW block is very similar to ALSA resampling feature, so looks like duplication.

11:11 <rockosov> But SoC loopback is working much better than simple aloop driver, because it's not depending on scheduling timings.

11:11 <rockosov> In the one device from our line we are using SoC Loopback to analyze captured audio data as a reference for AEC and VQE algorithms.

11:11 <rockosov> We have tested both SoC HW Loopback and aloop driver (sync version from mainline and our async version).

11:11 <rockosov> Aloop had very bad problem inside regarding queues of data chunks and task scheduling influence.

11:11 <rockosov> SoC loopback is total HW IP block, so it's more "realtime" let's say.

13:01 <jbrunet> The problem for the loopback is how to provide the stream parameters for each of the paths. Alsa does not provide a clean API for that. AML method, which is hardcoding the parameters in DT, is big NO. I guess I'll soon find out :)

18:13 <rockosov> jbrunet: I hope so :)