[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <cover.1592419750.git.mchehab+huawei@kernel.org>
Date: Wed, 17 Jun 2020 20:52:10 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Linux Media Mailing List <linux-media@...r.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
Marc Gonzalez <marc.w.gonzalez@...e.fr>,
Brad Love <brad@...tdimension.cc>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>,
Masahiro Yamada <masahiroy@...nel.org>,
linux-kernel@...r.kernel.org, Sean Young <sean@...s.org>,
devel@...verdev.osuosl.org,
Sakari Ailus <sakari.ailus@...ux.intel.com>
Subject: [RFC 0/4] Don't do tuning zigzag using the very same frequency
Marc reported on IRC that the zigzag code is trying to tune several times using
the same frequency with si2168. Well, this is not how this would be supposed
to do: it should try with different frequencies each time.
Change the core to use the one-shot mode if the frontend doesn't report a
frequency step. This will default to the current behavior, except that tuning
should be faster.
Yet, probably the right thing to do is to implement a frequency shift at such
frontends, as otherwise tuning may have problems. So, produce a warning
on such cases, in order for the FE driver to be fixed.
Mauro Carvalho Chehab (4):
media: atomisp: fix identation at I2C Kconfig menu
media: atomisp: fix help message for ISP2401 selection
media: dvb_frontend: move algo-specific settings to a function
media: dvb_frontend: disable zigzag mode if not possible
drivers/media/dvb-core/dvb_frontend.c | 231 ++++++++++--------
drivers/staging/media/atomisp/Kconfig | 2 +-
drivers/staging/media/atomisp/i2c/Kconfig | 74 +++---
.../staging/media/atomisp/i2c/ov5693/Kconfig | 12 -
4 files changed, 171 insertions(+), 148 deletions(-)
delete mode 100644 drivers/staging/media/atomisp/i2c/ov5693/Kconfig
--
2.26.2
Powered by blists - more mailing lists