22 лютого 2023 р. 11:21:02 GMT+02:00, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> написав(-ла): >On Wed, Feb 22, 2023 at 10:19:47AM +0200, Svyatoslav Ryhel wrote: >> вт, 21 лют. 2023 р. о 21:27 Greg Kroah-Hartman >> <gregkh@xxxxxxxxxxxxxxxxxxx> пише: >> > >> > On Tue, Feb 21, 2023 at 08:32:10PM +0200, Svyatoslav Ryhel wrote: >> > > FM34NE is digital sound processing chip used for active >> > > noise suppression mainly on ASUS Transformers. >> > > >> > > Signed-off-by: Svyatoslav Ryhel <clamor95@xxxxxxxxx> >> > > --- >> > > drivers/staging/Kconfig | 2 + >> > > drivers/staging/Makefile | 1 + >> > > drivers/staging/dsp/Kconfig | 7 + >> > > drivers/staging/dsp/Makefile | 2 + >> > > drivers/staging/dsp/dsp-fm34ne.c | 364 +++++++++++++ >> > > drivers/staging/dsp/dsp-fm34ne.h | 845 +++++++++++++++++++++++++++++++ >> > > 6 files changed, 1221 insertions(+) >> > > create mode 100644 drivers/staging/dsp/Kconfig >> > > create mode 100644 drivers/staging/dsp/Makefile >> > > create mode 100644 drivers/staging/dsp/dsp-fm34ne.c >> > > create mode 100644 drivers/staging/dsp/dsp-fm34ne.h >> > >> > >> > Sorry, but why is this going into drivers/staging/ at all? What is >> > needed to be done to get this out of staging? Why not do that work >> > right now? At the least, we need a TODO file in the directory that >> > lists what needs to be done and who is responsible for it. >> >> Because this driver sets up fm34 and switches it to bypass mode allowing >> sound to work on the device. There is no dsp framework in kernel which could >> be called to operate dsp from the actual sound codec. (If there is, I >> would be glad >> if you show me). Fm34 must be active only on DMIC use, all other cases require >> it to be in bypass. > >That does not explain at all why this needs to go into drivers/staging/ >and not the normal portion of the kernel. Why this specific location? >What is wrong with it that requires it to go here? It is not fully functional and does not perform its main function (noise cancellation) because it has to be called only for DMIC. Same time it is essential to be set so that audio could work on device. Once there is such a framework in kernel, which allows to control dsp from, I assume, asoc machine driver, this driver can be moved wherever it should be. Currently I can not tell where it should be since I haven't seen dsp drivers like this in kernel. >In other words, you need to document _WHY_ it must go here as it is not >obvious at all. > >thanks, > >greg k-h
