* [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
@ 2018-06-21 3:17 Katsuhiro Suzuki
2018-07-04 16:58 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-06-21 3:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab, linux-media
Cc: Masami Hiramatsu, Jassi Brar, linux-arm-kernel, linux-kernel,
Katsuhiro Suzuki
This patch adds a frontend driver for the Socionext SC1501A series
and Socionext MN88443x ISDB-S/T demodulators.
The maximum and minimum frequency of Socionext SC1501A comes from
ISDB-S and ISDB-T so frequency range is the following:
- ISDB-S (BS/CS110 IF frequency in kHz, Local freq 10.678GHz)
- Min: BS-1: 1032000 => 1032.23MHz
- Max: ND24: 2701000 => 2070.25MHz
- ISDB-T (in Hz)
- Min: ch13: 470000000 => 470.357857MHz
- Max: ch62: 770000000 => 769.927857MHz
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
Changes since v2:
- Fix frequency max and min
Changes since v1:
- Fix sparse warning about type of constant
- Use div_s64() instead of divide operator
---
drivers/media/dvb-frontends/Kconfig | 10 +
drivers/media/dvb-frontends/Makefile | 1 +
drivers/media/dvb-frontends/sc1501a.c | 802 ++++++++++++++++++++++++++
drivers/media/dvb-frontends/sc1501a.h | 27 +
4 files changed, 840 insertions(+)
create mode 100644 drivers/media/dvb-frontends/sc1501a.c
create mode 100644 drivers/media/dvb-frontends/sc1501a.h
diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig
index 9ecaa9d0744a..097ae3c834f2 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -739,6 +739,16 @@ config DVB_TC90522
Toshiba TC90522 2xISDB-S 8PSK + 2xISDB-T OFDM demodulator.
Say Y when you want to support this frontend.
+config DVB_SC1501A
+ tristate "Socionext SC1501A"
+ depends on DVB_CORE && I2C
+ select REGMAP_I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ A driver for Socionext SC1501A and Panasonic MN88443x
+ ISDB-S + ISDB-T demodulator.
+ Say Y when you want to support this frontend.
+
comment "Digital terrestrial only tuners/PLL"
depends on DVB_CORE
diff --git a/drivers/media/dvb-frontends/Makefile b/drivers/media/dvb-frontends/Makefile
index 67a783fd5ed0..e204502347ed 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -125,6 +125,7 @@ obj-$(CONFIG_DVB_AF9033) += af9033.o
obj-$(CONFIG_DVB_AS102_FE) += as102_fe.o
obj-$(CONFIG_DVB_GP8PSK_FE) += gp8psk-fe.o
obj-$(CONFIG_DVB_TC90522) += tc90522.o
+obj-$(CONFIG_DVB_SC1501A) += sc1501a.o
obj-$(CONFIG_DVB_HORUS3A) += horus3a.o
obj-$(CONFIG_DVB_ASCOT2E) += ascot2e.o
obj-$(CONFIG_DVB_HELENE) += helene.o
diff --git a/drivers/media/dvb-frontends/sc1501a.c b/drivers/media/dvb-frontends/sc1501a.c
new file mode 100644
index 000000000000..705529007abe
--- /dev/null
+++ b/drivers/media/dvb-frontends/sc1501a.c
@@ -0,0 +1,802 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Socionext SC1501A series demodulator driver for ISDB-S/ISDB-T.
+//
+// Copyright (c) 2018 Socionext Inc.
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <media/dvb_math.h>
+
+#include "sc1501a.h"
+
+/* ISDB-S registers */
+#define ATSIDU_S 0x2f
+#define ATSIDL_S 0x30
+#define TSSET_S 0x31
+#define AGCREAD_S 0x5a
+#define CPMON1_S 0x5e
+#define CPMON1_S_FSYNC BIT(5)
+#define CPMON1_S_ERRMON BIT(4)
+#define CPMON1_S_SIGOFF BIT(3)
+#define CPMON1_S_W2LOCK BIT(2)
+#define CPMON1_S_W1LOCK BIT(1)
+#define CPMON1_S_DW1LOCK BIT(0)
+#define TRMON_S 0x60
+#define BERCNFLG_S 0x68
+#define BERCNFLG_S_BERVRDY BIT(5)
+#define BERCNFLG_S_BERVCHK BIT(4)
+#define BERCNFLG_S_BERDRDY BIT(3)
+#define BERCNFLG_S_BERDCHK BIT(2)
+#define CNRDXU_S 0x69
+#define CNRDXL_S 0x6a
+#define CNRDYU_S 0x6b
+#define CNRDYL_S 0x6c
+#define BERVRDU_S 0x71
+#define BERVRDL_S 0x72
+#define DOSET1_S 0x73
+
+/* Primary ISDB-T */
+#define PLLASET1 0x00
+#define PLLASET2 0x01
+#define PLLBSET1 0x02
+#define PLLBSET2 0x03
+#define PLLSET 0x04
+#define OUTCSET 0x08
+#define OUTCSET_CHDRV_8MA 0xff
+#define OUTCSET_CHDRV_4MA 0x00
+#define PLDWSET 0x09
+#define PLDWSET_NORMAL 0x00
+#define PLDWSET_PULLDOWN 0xff
+#define HIZSET1 0x0a
+#define HIZSET2 0x0b
+
+/* Secondary ISDB-T (for MN884434 only) */
+#define RCVSET 0x00
+#define TSSET1_M 0x01
+#define TSSET2_M 0x02
+#define TSSET3_M 0x03
+#define INTACSET 0x08
+#define HIZSET3 0x0b
+
+/* ISDB-T registers */
+#define TSSET1 0x05
+#define TSSET1_TSASEL_MASK GENMASK(4, 3)
+#define TSSET1_TSASEL_ISDBT (0x0 << 3)
+#define TSSET1_TSASEL_ISDBS (0x1 << 3)
+#define TSSET1_TSASEL_NONE (0x2 << 3)
+#define TSSET1_TSBSEL_MASK GENMASK(2, 1)
+#define TSSET1_TSBSEL_ISDBS (0x0 << 1)
+#define TSSET1_TSBSEL_ISDBT (0x1 << 1)
+#define TSSET1_TSBSEL_NONE (0x2 << 1)
+#define TSSET2 0x06
+#define TSSET3 0x07
+#define TSSET3_INTASEL_MASK GENMASK(7, 6)
+#define TSSET3_INTASEL_T (0x0 << 6)
+#define TSSET3_INTASEL_S (0x1 << 6)
+#define TSSET3_INTASEL_NONE (0x2 << 6)
+#define TSSET3_INTBSEL_MASK GENMASK(5, 4)
+#define TSSET3_INTBSEL_S (0x0 << 4)
+#define TSSET3_INTBSEL_T (0x1 << 4)
+#define TSSET3_INTBSEL_NONE (0x2 << 4)
+#define OUTSET2 0x0d
+#define PWDSET 0x0f
+#define PWDSET_OFDMPD_MASK GENMASK(3, 2)
+#define PWDSET_OFDMPD_DOWN BIT(3)
+#define PWDSET_PSKPD_MASK GENMASK(1, 0)
+#define PWDSET_PSKPD_DOWN BIT(1)
+#define CLKSET1_T 0x11
+#define MDSET_T 0x13
+#define MDSET_T_MDAUTO_MASK GENMASK(7, 4)
+#define MDSET_T_MDAUTO_AUTO (0xf << 4)
+#define MDSET_T_MDAUTO_MANUAL (0x0 << 4)
+#define MDSET_T_FFTS_MASK GENMASK(3, 2)
+#define MDSET_T_FFTS_MODE1 (0x0 << 2)
+#define MDSET_T_FFTS_MODE2 (0x1 << 2)
+#define MDSET_T_FFTS_MODE3 (0x2 << 2)
+#define MDSET_T_GI_MASK GENMASK(1, 0)
+#define MDSET_T_GI_1_32 (0x0 << 0)
+#define MDSET_T_GI_1_16 (0x1 << 0)
+#define MDSET_T_GI_1_8 (0x2 << 0)
+#define MDSET_T_GI_1_4 (0x3 << 0)
+#define MDASET_T 0x14
+#define ADCSET1_T 0x20
+#define ADCSET1_T_REFSEL_MASK GENMASK(1, 0)
+#define ADCSET1_T_REFSEL_2V (0x3 << 0)
+#define ADCSET1_T_REFSEL_1_5V (0x2 << 0)
+#define ADCSET1_T_REFSEL_1V (0x1 << 0)
+#define NCOFREQU_T 0x24
+#define NCOFREQM_T 0x25
+#define NCOFREQL_T 0x26
+#define FADU_T 0x27
+#define FADM_T 0x28
+#define FADL_T 0x29
+#define AGCSET2_T 0x2c
+#define AGCSET2_T_IFPOLINV_INC BIT(0)
+#define AGCSET2_T_RFPOLINV_INC BIT(1)
+#define AGCV3_T 0x3e
+#define MDRD_T 0xa2
+#define MDRD_T_SEGID_MASK GENMASK(5, 4)
+#define MDRD_T_SEGID_13 (0x0 << 4)
+#define MDRD_T_SEGID_1 (0x1 << 4)
+#define MDRD_T_SEGID_3 (0x2 << 4)
+#define MDRD_T_FFTS_MASK GENMASK(3, 2)
+#define MDRD_T_FFTS_MODE1 (0x0 << 2)
+#define MDRD_T_FFTS_MODE2 (0x1 << 2)
+#define MDRD_T_FFTS_MODE3 (0x2 << 2)
+#define MDRD_T_GI_MASK GENMASK(1, 0)
+#define MDRD_T_GI_1_32 (0x0 << 0)
+#define MDRD_T_GI_1_16 (0x1 << 0)
+#define MDRD_T_GI_1_8 (0x2 << 0)
+#define MDRD_T_GI_1_4 (0x3 << 0)
+#define SSEQRD_T 0xa3
+#define SSEQRD_T_SSEQSTRD_MASK GENMASK(3, 0)
+#define SSEQRD_T_SSEQSTRD_RESET (0x0 << 0)
+#define SSEQRD_T_SSEQSTRD_TUNING (0x1 << 0)
+#define SSEQRD_T_SSEQSTRD_AGC (0x2 << 0)
+#define SSEQRD_T_SSEQSTRD_SEARCH (0x3 << 0)
+#define SSEQRD_T_SSEQSTRD_CLOCK_SYNC (0x4 << 0)
+#define SSEQRD_T_SSEQSTRD_FREQ_SYNC (0x8 << 0)
+#define SSEQRD_T_SSEQSTRD_FRAME_SYNC (0x9 << 0)
+#define SSEQRD_T_SSEQSTRD_SYNC (0xa << 0)
+#define SSEQRD_T_SSEQSTRD_LOCK (0xb << 0)
+#define AGCRDU_T 0xa8
+#define AGCRDL_T 0xa9
+#define CNRDU_T 0xbe
+#define CNRDL_T 0xbf
+#define BERFLG_T 0xc0
+#define BERFLG_T_BERDRDY BIT(7)
+#define BERFLG_T_BERDCHK BIT(6)
+#define BERFLG_T_BERVRDYA BIT(5)
+#define BERFLG_T_BERVCHKA BIT(4)
+#define BERFLG_T_BERVRDYB BIT(3)
+#define BERFLG_T_BERVCHKB BIT(2)
+#define BERFLG_T_BERVRDYC BIT(1)
+#define BERFLG_T_BERVCHKC BIT(0)
+#define BERRDU_T 0xc1
+#define BERRDM_T 0xc2
+#define BERRDL_T 0xc3
+#define BERLENRDU_T 0xc4
+#define BERLENRDL_T 0xc5
+#define ERRFLG_T 0xc6
+#define ERRFLG_T_BERDOVF BIT(7)
+#define ERRFLG_T_BERVOVFA BIT(6)
+#define ERRFLG_T_BERVOVFB BIT(5)
+#define ERRFLG_T_BERVOVFC BIT(4)
+#define ERRFLG_T_NERRFA BIT(3)
+#define ERRFLG_T_NERRFB BIT(2)
+#define ERRFLG_T_NERRFC BIT(1)
+#define ERRFLG_T_NERRF BIT(0)
+#define DOSET1_T 0xcf
+
+#define CLK_LOW 4000000
+#define CLK_DIRECT 20200000
+#define CLK_MAX 25410000
+
+#define S_T_FREQ 8126984 /* 512 / 63 MHz */
+
+struct sc1501a_spec {
+ bool primary;
+};
+
+struct sc1501a_priv {
+ const struct sc1501a_spec *spec;
+
+ struct dvb_frontend fe;
+ struct clk *mclk;
+ struct gpio_desc *reset_gpio;
+ u32 clk_freq;
+ u32 if_freq;
+
+ /* Common */
+ bool use_clkbuf;
+
+ /* ISDB-S */
+ struct i2c_client *client_s;
+ struct regmap *regmap_s;
+
+ /* ISDB-T */
+ struct i2c_client *client_t;
+ struct regmap *regmap_t;
+};
+
+static void sc1501a_cmn_power_on(struct sc1501a_priv *chip)
+{
+ struct regmap *r_t = chip->regmap_t;
+
+ clk_prepare_enable(chip->mclk);
+
+ gpiod_set_value_cansleep(chip->reset_gpio, 1);
+ usleep_range(100, 1000);
+ gpiod_set_value_cansleep(chip->reset_gpio, 0);
+
+ if (chip->spec->primary) {
+ regmap_write(r_t, OUTCSET, OUTCSET_CHDRV_8MA);
+ regmap_write(r_t, PLDWSET, PLDWSET_NORMAL);
+ regmap_write(r_t, HIZSET1, 0x80);
+ regmap_write(r_t, HIZSET2, 0xe0);
+ } else {
+ regmap_write(r_t, HIZSET3, 0x8f);
+ }
+}
+
+static void sc1501a_cmn_power_off(struct sc1501a_priv *chip)
+{
+ gpiod_set_value_cansleep(chip->reset_gpio, 1);
+
+ clk_disable_unprepare(chip->mclk);
+}
+
+static void sc1501a_s_sleep(struct sc1501a_priv *chip)
+{
+ struct regmap *r_t = chip->regmap_t;
+
+ regmap_update_bits(r_t, PWDSET, PWDSET_PSKPD_MASK,
+ PWDSET_PSKPD_DOWN);
+}
+
+static void sc1501a_s_wake(struct sc1501a_priv *chip)
+{
+ struct regmap *r_t = chip->regmap_t;
+
+ regmap_update_bits(r_t, PWDSET, PWDSET_PSKPD_MASK, 0);
+}
+
+static void sc1501a_s_tune(struct sc1501a_priv *chip,
+ struct dtv_frontend_properties *c)
+{
+ struct regmap *r_s = chip->regmap_s;
+
+ regmap_write(r_s, ATSIDU_S, c->stream_id >> 8);
+ regmap_write(r_s, ATSIDL_S, c->stream_id);
+ regmap_write(r_s, TSSET_S, 0);
+}
+
+static int sc1501a_s_read_status(struct sc1501a_priv *chip,
+ struct dtv_frontend_properties *c,
+ enum fe_status *status)
+{
+ struct regmap *r_s = chip->regmap_s;
+ u32 cpmon, tmpu, tmpl, flg;
+ u64 tmp;
+
+ /* Sync detection */
+ regmap_read(r_s, CPMON1_S, &cpmon);
+
+ *status = 0;
+ if (cpmon & CPMON1_S_FSYNC)
+ *status |= FE_HAS_VITERBI | FE_HAS_SYNC | FE_HAS_LOCK;
+ if (cpmon & CPMON1_S_W2LOCK)
+ *status |= FE_HAS_SIGNAL | FE_HAS_CARRIER;
+
+ /* Signal strength */
+ c->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
+ if (*status & FE_HAS_SIGNAL) {
+ u32 agc;
+
+ regmap_read(r_s, AGCREAD_S, &tmpu);
+ agc = tmpu << 8;
+
+ c->strength.len = 1;
+ c->strength.stat[0].scale = FE_SCALE_RELATIVE;
+ c->strength.stat[0].uvalue = agc;
+ }
+
+ /* C/N rate */
+ c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
+ if (*status & FE_HAS_VITERBI) {
+ u32 cnr = 0, x, y, d;
+ u64 d_3 = 0;
+
+ regmap_read(r_s, CNRDXU_S, &tmpu);
+ regmap_read(r_s, CNRDXL_S, &tmpl);
+ x = (tmpu << 8) | tmpl;
+ regmap_read(r_s, CNRDYU_S, &tmpu);
+ regmap_read(r_s, CNRDYL_S, &tmpl);
+ y = (tmpu << 8) | tmpl;
+
+ /* CNR[dB]: 10 * log10(D) - 30.74 / D^3 - 3 */
+ /* D = x^2 / (2^15 * y - x^2) */
+ d = (y << 15) - x * x;
+ if (d > 0) {
+ /* (2^4 * D)^3 = 2^12 * D^3 */
+ /* 3.074 * 2^(12 + 24) = 211243671486 */
+ d_3 = div_u64(16 * x * x, d);
+ d_3 = d_3 * d_3 * d_3;
+ if (d_3)
+ d_3 = div_u64(211243671486ULL, d_3);
+ }
+
+ if (d_3) {
+ /* 0.3 * 2^24 = 5033164 */
+ tmp = (s64)2 * intlog10(x) - intlog10(abs(d)) - d_3
+ - 5033164;
+ cnr = div_u64(tmp * 10000, 1 << 24);
+ }
+
+ if (cnr) {
+ c->cnr.len = 1;
+ c->cnr.stat[0].scale = FE_SCALE_DECIBEL;
+ c->cnr.stat[0].uvalue = cnr;
+ }
+ }
+
+ /* BER */
+ c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
+ regmap_read(r_s, BERCNFLG_S, &flg);
+
+ if ((*status & FE_HAS_VITERBI) && (flg & BERCNFLG_S_BERVRDY)) {
+ u32 bit_err, bit_cnt;
+
+ regmap_read(r_s, BERVRDU_S, &tmpu);
+ regmap_read(r_s, BERVRDL_S, &tmpl);
+ bit_err = (tmpu << 8) | tmpl;
+ bit_cnt = (1 << 13) * 204;
+
+ if (bit_cnt) {
+ c->post_bit_error.len = 1;
+ c->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
+ c->post_bit_error.stat[0].uvalue = bit_err;
+ c->post_bit_count.len = 1;
+ c->post_bit_count.stat[0].scale = FE_SCALE_COUNTER;
+ c->post_bit_count.stat[0].uvalue = bit_cnt;
+ }
+ }
+
+ return 0;
+}
+
+static void sc1501a_t_sleep(struct sc1501a_priv *chip)
+{
+ struct regmap *r_t = chip->regmap_t;
+
+ regmap_update_bits(r_t, PWDSET, PWDSET_OFDMPD_MASK,
+ PWDSET_OFDMPD_DOWN);
+}
+
+static void sc1501a_t_wake(struct sc1501a_priv *chip)
+{
+ struct regmap *r_t = chip->regmap_t;
+
+ regmap_update_bits(r_t, PWDSET, PWDSET_OFDMPD_MASK, 0);
+}
+
+static bool sc1501a_t_is_valid_clk(u32 adckt, u32 if_freq)
+{
+ if (if_freq == DIRECT_IF_57MHZ) {
+ if (adckt >= CLK_DIRECT && adckt <= 21000000)
+ return true;
+ if (adckt >= 25300000 && adckt <= CLK_MAX)
+ return true;
+ } else if (if_freq == DIRECT_IF_44MHZ) {
+ if (adckt >= 25000000 && adckt <= CLK_MAX)
+ return true;
+ } else if (if_freq >= LOW_IF_4MHZ && if_freq < DIRECT_IF_44MHZ) {
+ if (adckt >= CLK_DIRECT && adckt <= CLK_MAX)
+ return true;
+ }
+
+ return false;
+}
+
+static int sc1501a_t_set_freq(struct sc1501a_priv *chip)
+{
+ struct device *dev = &chip->client_s->dev;
+ struct regmap *r_t = chip->regmap_t;
+ s64 adckt, nco, ad_t;
+ u32 m, v;
+
+ /* Clock buffer (but not supported) or XTAL */
+ if (chip->clk_freq >= CLK_LOW && chip->clk_freq < CLK_DIRECT) {
+ chip->use_clkbuf = true;
+ regmap_write(r_t, CLKSET1_T, 0x07);
+
+ adckt = 0;
+ } else {
+ chip->use_clkbuf = false;
+ regmap_write(r_t, CLKSET1_T, 0x00);
+
+ adckt = chip->clk_freq;
+ }
+ if (!sc1501a_t_is_valid_clk(adckt, chip->if_freq)) {
+ dev_err(dev, "Invalid clock, CLK:%d, ADCKT:%lld, IF:%d\n",
+ chip->clk_freq, adckt, chip->if_freq);
+ return -EINVAL;
+ }
+
+ /* Direct IF or Low IF */
+ if (chip->if_freq == DIRECT_IF_57MHZ ||
+ chip->if_freq == DIRECT_IF_44MHZ)
+ nco = adckt * 2 - chip->if_freq;
+ else
+ nco = -((s64)chip->if_freq);
+ nco = div_s64(nco << 24, adckt);
+ ad_t = div_s64(adckt << 22, S_T_FREQ);
+
+ regmap_write(r_t, NCOFREQU_T, nco >> 16);
+ regmap_write(r_t, NCOFREQM_T, nco >> 8);
+ regmap_write(r_t, NCOFREQL_T, nco);
+ regmap_write(r_t, FADU_T, ad_t >> 16);
+ regmap_write(r_t, FADM_T, ad_t >> 8);
+ regmap_write(r_t, FADL_T, ad_t);
+
+ /* Level of IF */
+ m = ADCSET1_T_REFSEL_MASK;
+ v = ADCSET1_T_REFSEL_1_5V;
+ regmap_update_bits(r_t, ADCSET1_T, m, v);
+
+ /* Polarity of AGC */
+ v = AGCSET2_T_IFPOLINV_INC | AGCSET2_T_RFPOLINV_INC;
+ regmap_update_bits(r_t, AGCSET2_T, v, v);
+
+ /* Lower output level of AGC */
+ regmap_write(r_t, AGCV3_T, 0x00);
+
+ regmap_write(r_t, MDSET_T, 0xfa);
+
+ return 0;
+}
+
+static void sc1501a_t_tune(struct sc1501a_priv *chip,
+ struct dtv_frontend_properties *c)
+{
+ struct regmap *r_t = chip->regmap_t;
+ u32 m, v;
+
+ m = MDSET_T_MDAUTO_MASK | MDSET_T_FFTS_MASK | MDSET_T_GI_MASK;
+ v = MDSET_T_MDAUTO_AUTO | MDSET_T_FFTS_MODE3 | MDSET_T_GI_1_8;
+ regmap_update_bits(r_t, MDSET_T, m, v);
+
+ regmap_write(r_t, MDASET_T, 0);
+}
+
+static int sc1501a_t_read_status(struct sc1501a_priv *chip,
+ struct dtv_frontend_properties *c,
+ enum fe_status *status)
+{
+ struct regmap *r_t = chip->regmap_t;
+ u32 seqrd, st, flg, tmpu, tmpm, tmpl;
+ u64 tmp;
+
+ /* Sync detection */
+ regmap_read(r_t, SSEQRD_T, &seqrd);
+ st = seqrd & SSEQRD_T_SSEQSTRD_MASK;
+
+ *status = 0;
+ if (st >= SSEQRD_T_SSEQSTRD_SYNC)
+ *status |= FE_HAS_VITERBI | FE_HAS_SYNC | FE_HAS_LOCK;
+ if (st >= SSEQRD_T_SSEQSTRD_FRAME_SYNC)
+ *status |= FE_HAS_SIGNAL | FE_HAS_CARRIER;
+
+ /* Signal strength */
+ c->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
+ if (*status & FE_HAS_SIGNAL) {
+ u32 agc;
+
+ regmap_read(r_t, AGCRDU_T, &tmpu);
+ regmap_read(r_t, AGCRDL_T, &tmpl);
+ agc = (tmpu << 8) | tmpl;
+
+ c->strength.len = 1;
+ c->strength.stat[0].scale = FE_SCALE_RELATIVE;
+ c->strength.stat[0].uvalue = agc;
+ }
+
+ /* C/N rate */
+ c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
+ if (*status & FE_HAS_VITERBI) {
+ u32 cnr;
+
+ regmap_read(r_t, CNRDU_T, &tmpu);
+ regmap_read(r_t, CNRDL_T, &tmpl);
+
+ if (tmpu || tmpl) {
+ /* CNR[dB]: 10 * (log10(65536 / value) + 0.2) */
+ /* intlog10(65536) = 80807124, 0.2 * 2^24 = 3355443 */
+ tmp = (u64)80807124 - intlog10((tmpu << 8) | tmpl)
+ + 3355443;
+ cnr = div_u64(tmp * 10000, 1 << 24);
+ } else {
+ cnr = 0;
+ }
+
+ c->cnr.len = 1;
+ c->cnr.stat[0].scale = FE_SCALE_DECIBEL;
+ c->cnr.stat[0].uvalue = cnr;
+ }
+
+ /* BER */
+ c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
+ regmap_read(r_t, BERFLG_T, &flg);
+
+ if ((*status & FE_HAS_VITERBI) && (flg & BERFLG_T_BERVRDYA)) {
+ u32 bit_err, bit_cnt;
+
+ regmap_read(r_t, BERRDU_T, &tmpu);
+ regmap_read(r_t, BERRDM_T, &tmpm);
+ regmap_read(r_t, BERRDL_T, &tmpl);
+ bit_err = (tmpu << 16) | (tmpm << 8) | tmpl;
+
+ regmap_read(r_t, BERLENRDU_T, &tmpu);
+ regmap_read(r_t, BERLENRDL_T, &tmpl);
+ bit_cnt = ((tmpu << 8) | tmpl) * 203 * 8;
+
+ if (bit_cnt) {
+ c->post_bit_error.len = 1;
+ c->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
+ c->post_bit_error.stat[0].uvalue = bit_err;
+ c->post_bit_count.len = 1;
+ c->post_bit_count.stat[0].scale = FE_SCALE_COUNTER;
+ c->post_bit_count.stat[0].uvalue = bit_cnt;
+ }
+ }
+
+ return 0;
+}
+
+static int sc1501a_sleep(struct dvb_frontend *fe)
+{
+ struct sc1501a_priv *chip = fe->demodulator_priv;
+
+ sc1501a_s_sleep(chip);
+ sc1501a_t_sleep(chip);
+
+ return 0;
+}
+
+static int sc1501a_set_frontend(struct dvb_frontend *fe)
+{
+ struct sc1501a_priv *chip = fe->demodulator_priv;
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+ struct regmap *r_s = chip->regmap_s;
+ struct regmap *r_t = chip->regmap_t;
+ u8 tssel = 0, intsel = 0;
+
+ if (c->delivery_system == SYS_ISDBS) {
+ sc1501a_s_wake(chip);
+ sc1501a_t_sleep(chip);
+
+ tssel = TSSET1_TSASEL_ISDBS;
+ intsel = TSSET3_INTASEL_S;
+ } else if (c->delivery_system == SYS_ISDBT) {
+ sc1501a_s_sleep(chip);
+ sc1501a_t_wake(chip);
+
+ sc1501a_t_set_freq(chip);
+
+ tssel = TSSET1_TSASEL_ISDBT;
+ intsel = TSSET3_INTASEL_T;
+ }
+
+ regmap_update_bits(r_t, TSSET1,
+ TSSET1_TSASEL_MASK | TSSET1_TSBSEL_MASK,
+ tssel | TSSET1_TSBSEL_NONE);
+ regmap_write(r_t, TSSET2, 0);
+ regmap_update_bits(r_t, TSSET3,
+ TSSET3_INTASEL_MASK | TSSET3_INTBSEL_MASK,
+ intsel | TSSET3_INTBSEL_NONE);
+
+ regmap_write(r_t, DOSET1_T, 0x95);
+ regmap_write(r_s, DOSET1_S, 0x80);
+
+ if (c->delivery_system == SYS_ISDBS)
+ sc1501a_s_tune(chip, c);
+ else if (c->delivery_system == SYS_ISDBT)
+ sc1501a_t_tune(chip, c);
+
+ if (fe->ops.tuner_ops.set_params) {
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 1);
+ fe->ops.tuner_ops.set_params(fe);
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 0);
+ }
+
+ return 0;
+}
+
+static int sc1501a_get_tune_settings(struct dvb_frontend *fe,
+ struct dvb_frontend_tune_settings *s)
+{
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+ s->min_delay_ms = 850;
+
+ if (c->delivery_system == SYS_ISDBS) {
+ s->max_drift = 30000 * 2 + 1;
+ s->step_size = 30000;
+ } else if (c->delivery_system == SYS_ISDBT) {
+ s->max_drift = 142857 * 2 + 1;
+ s->step_size = 142857 * 2;
+ }
+
+ return 0;
+}
+
+static int sc1501a_read_status(struct dvb_frontend *fe, enum fe_status *status)
+{
+ struct sc1501a_priv *chip = fe->demodulator_priv;
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+ if (c->delivery_system == SYS_ISDBS)
+ return sc1501a_s_read_status(chip, c, status);
+
+ if (c->delivery_system == SYS_ISDBT)
+ return sc1501a_t_read_status(chip, c, status);
+
+ return -EINVAL;
+}
+
+static const struct dvb_frontend_ops sc1501a_ops = {
+ .delsys = { SYS_ISDBS, SYS_ISDBT },
+ .info = {
+ .name = "Socionext SC1501A",
+ .frequency_min = 1032000,
+ .frequency_max = 770000000,
+ .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
+ FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
+ FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
+ },
+
+ .sleep = sc1501a_sleep,
+ .set_frontend = sc1501a_set_frontend,
+ .get_tune_settings = sc1501a_get_tune_settings,
+ .read_status = sc1501a_read_status,
+};
+
+static const struct regmap_config regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .cache_type = REGCACHE_NONE,
+};
+
+static int sc1501a_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct sc1501a_config *conf = client->dev.platform_data;
+ struct sc1501a_priv *chip;
+ struct device *dev = &client->dev;
+ int ret;
+
+ chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ if (dev->of_node)
+ chip->spec = of_device_get_match_data(dev);
+ else
+ chip->spec = (struct sc1501a_spec *)id->driver_data;
+ if (!chip->spec)
+ return -EINVAL;
+
+ chip->mclk = devm_clk_get(dev, "mclk");
+ if (IS_ERR(chip->mclk) && !conf) {
+ dev_err(dev, "Failed to request mclk: %ld\n",
+ PTR_ERR(chip->mclk));
+ return PTR_ERR(chip->mclk);
+ }
+
+ ret = of_property_read_u32(dev->of_node, "if-frequency",
+ &chip->if_freq);
+ if (ret && !conf) {
+ dev_err(dev, "Failed to load IF frequency: %d.\n", ret);
+ return ret;
+ }
+
+ chip->reset_gpio = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(chip->reset_gpio)) {
+ dev_err(dev, "Failed to request reset_gpio: %ld\n",
+ PTR_ERR(chip->reset_gpio));
+ return PTR_ERR(chip->reset_gpio);
+ }
+
+ if (conf) {
+ chip->mclk = conf->mclk;
+ chip->if_freq = conf->if_freq;
+ chip->reset_gpio = conf->reset_gpio;
+
+ *conf->fe = &chip->fe;
+ }
+
+ chip->client_s = client;
+ chip->regmap_s = devm_regmap_init_i2c(chip->client_s, ®map_config);
+ if (IS_ERR(chip->regmap_s))
+ return PTR_ERR(chip->regmap_s);
+
+ /*
+ * Chip has two I2C addresses for each satellite/terrestrial system.
+ * ISDB-T uses address ISDB-S + 4, so we register a dummy client.
+ */
+ chip->client_t = i2c_new_dummy(client->adapter, client->addr + 4);
+ if (!chip->client_t)
+ return -ENODEV;
+
+ chip->regmap_t = devm_regmap_init_i2c(chip->client_t, ®map_config);
+ if (IS_ERR(chip->regmap_t)) {
+ ret = PTR_ERR(chip->regmap_t);
+ goto err_i2c_t;
+ }
+
+ chip->clk_freq = clk_get_rate(chip->mclk);
+
+ memcpy(&chip->fe.ops, &sc1501a_ops, sizeof(sc1501a_ops));
+ chip->fe.demodulator_priv = chip;
+ i2c_set_clientdata(client, chip);
+
+ sc1501a_cmn_power_on(chip);
+ sc1501a_s_sleep(chip);
+ sc1501a_t_sleep(chip);
+
+ return 0;
+
+err_i2c_t:
+ i2c_unregister_device(chip->client_t);
+
+ return ret;
+}
+
+static int sc1501a_remove(struct i2c_client *client)
+{
+ struct sc1501a_priv *chip = i2c_get_clientdata(client);
+
+ sc1501a_cmn_power_off(chip);
+
+ i2c_unregister_device(chip->client_t);
+
+ return 0;
+}
+
+static const struct sc1501a_spec sc1501a_spec_pri = {
+ .primary = true,
+};
+
+static const struct sc1501a_spec sc1501a_spec_sec = {
+ .primary = false,
+};
+
+static const struct of_device_id sc1501a_of_match[] = {
+ { .compatible = "socionext,mn884433", .data = &sc1501a_spec_pri, },
+ { .compatible = "socionext,mn884434-0", .data = &sc1501a_spec_pri, },
+ { .compatible = "socionext,mn884434-1", .data = &sc1501a_spec_sec, },
+ { .compatible = "socionext,sc1501a", .data = &sc1501a_spec_pri, },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sc1501a_of_match);
+
+static const struct i2c_device_id sc1501a_i2c_id[] = {
+ { "mn884433", (kernel_ulong_t)&sc1501a_spec_pri },
+ { "mn884434-0", (kernel_ulong_t)&sc1501a_spec_pri },
+ { "mn884434-1", (kernel_ulong_t)&sc1501a_spec_sec },
+ { "sc1501a", (kernel_ulong_t)&sc1501a_spec_pri },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, sc1501a_i2c_id);
+
+static struct i2c_driver sc1501a_driver = {
+ .driver = {
+ .name = "sc1501a",
+ .of_match_table = of_match_ptr(sc1501a_of_match),
+ },
+ .probe = sc1501a_probe,
+ .remove = sc1501a_remove,
+ .id_table = sc1501a_i2c_id,
+};
+
+module_i2c_driver(sc1501a_driver);
+
+MODULE_AUTHOR("Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>");
+MODULE_DESCRIPTION("Socionext SC1501A series demodulator driver.");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/dvb-frontends/sc1501a.h b/drivers/media/dvb-frontends/sc1501a.h
new file mode 100644
index 000000000000..7e247d44e4ac
--- /dev/null
+++ b/drivers/media/dvb-frontends/sc1501a.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Socionext SC1501A series demodulator driver for ISDB-S/ISDB-T.
+ *
+ * Copyright (c) 2018 Socionext Inc.
+ */
+
+#ifndef SC1501A_H
+#define SC1501A_H
+
+#include <media/dvb_frontend.h>
+
+/* ISDB-T IF frequency */
+#define DIRECT_IF_57MHZ 57000000
+#define DIRECT_IF_44MHZ 44000000
+#define LOW_IF_4MHZ 4000000
+
+struct sc1501a_config {
+ struct clk *mclk;
+ u32 if_freq;
+ struct gpio_desc *reset_gpio;
+
+ /* Everything after that is returned by the driver. */
+ struct dvb_frontend **fe;
+};
+
+#endif /* SC1501A_H */
--
2.17.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-06-21 3:17 [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver Katsuhiro Suzuki
@ 2018-07-04 16:58 ` Mauro Carvalho Chehab
2018-07-05 1:58 ` Katsuhiro Suzuki
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-04 16:58 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel
Hi Katsuhiro-san,
Em Thu, 21 Jun 2018 12:17:48 +0900
Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> escreveu:
> This patch adds a frontend driver for the Socionext SC1501A series
> and Socionext MN88443x ISDB-S/T demodulators.
Sorry for taking so long to review it. We're missing a sub-maintainer
for DVB, with would otherwise speed up reviews of DVB patches.
>
> The maximum and minimum frequency of Socionext SC1501A comes from
> ISDB-S and ISDB-T so frequency range is the following:
> - ISDB-S (BS/CS110 IF frequency in kHz, Local freq 10.678GHz)
> - Min: BS-1: 1032000 => 1032.23MHz
> - Max: ND24: 2701000 => 2070.25MHz
> - ISDB-T (in Hz)
> - Min: ch13: 470000000 => 470.357857MHz
> - Max: ch62: 770000000 => 769.927857MHz
There is actually an error on that part of the driver. Right now,
the DVB core expects Satellite frequencies (DVB-S, ISDB-S, ...)
in kHz. For all other delivery systems, it is in Hz.
It is this way due to historic reasons. While it won't be hard to
change the core, that would require to touch all Satellite drivers.
As there are very few frontend drivers that accept both Satellite
and Terrestrial standards, what we do, instead, is to setup
two frontends. See, for example, drivers/media/dvb-frontends/helene.c.
...
> +static const struct dvb_frontend_ops sc1501a_ops = {
> + .delsys = { SYS_ISDBS, SYS_ISDBT },
> + .info = {
> + .name = "Socionext SC1501A",
> + .frequency_min = 1032000,
> + .frequency_max = 770000000,
> + .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
> + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
> + FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
> + },
> +
> + .sleep = sc1501a_sleep,
> + .set_frontend = sc1501a_set_frontend,
> + .get_tune_settings = sc1501a_get_tune_settings,
> + .read_status = sc1501a_read_status,
> +};
In other words, you'll need to declare two structs here, one for ISDB-T
and another one for ISDB-S.
Yeah, I know that this sucks. If you are in the mood of touching the
DVB core, I'm willing to consider a patch that would fix this, provided
that it won't break backward compatibility with other drivers (or would
convert the other satellite drivers to use the new way).
Thanks,
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-04 16:58 ` Mauro Carvalho Chehab
@ 2018-07-05 1:58 ` Katsuhiro Suzuki
2018-07-05 2:42 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-07-05 1:58 UTC (permalink / raw)
To: 'Mauro Carvalho Chehab',
Suzuki, Katsuhiro/鈴木 勝博
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel
Hi Mauro,
> -----Original Message-----
> From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Sent: Thursday, July 5, 2018 1:58 AM
> To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> Cc: linux-media@vger.kernel.org; Masami Hiramatsu
<masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> demodulator driver
>
> Hi Katsuhiro-san,
>
> Em Thu, 21 Jun 2018 12:17:48 +0900
> Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> escreveu:
>
> > This patch adds a frontend driver for the Socionext SC1501A series
> > and Socionext MN88443x ISDB-S/T demodulators.
>
> Sorry for taking so long to review it. We're missing a sub-maintainer
> for DVB, with would otherwise speed up reviews of DVB patches.
No problem, thank you for reviewing! I appreciate it.
> >
> > The maximum and minimum frequency of Socionext SC1501A comes from
> > ISDB-S and ISDB-T so frequency range is the following:
> > - ISDB-S (BS/CS110 IF frequency in kHz, Local freq 10.678GHz)
> > - Min: BS-1: 1032000 => 1032.23MHz
> > - Max: ND24: 2701000 => 2070.25MHz
> > - ISDB-T (in Hz)
> > - Min: ch13: 470000000 => 470.357857MHz
> > - Max: ch62: 770000000 => 769.927857MHz
>
> There is actually an error on that part of the driver. Right now,
> the DVB core expects Satellite frequencies (DVB-S, ISDB-S, ...)
> in kHz. For all other delivery systems, it is in Hz.
>
> It is this way due to historic reasons. While it won't be hard to
> change the core, that would require to touch all Satellite drivers.
>
> As there are very few frontend drivers that accept both Satellite
> and Terrestrial standards, what we do, instead, is to setup
> two frontends. See, for example, drivers/media/dvb-frontends/helene.c.
>
Thank you for describing it. I understand our device is rare case, and
the reason why Helene has Terrestrial and Satellite structures.
I'm using MN884434 device that has 2 cores. I want to setup DVB adapter
devices (/dev/dvb/adapter0/*) for our frontend system as the following:
- adapter0: for core 0, ISDB-T, ISDB-S
- adapter1: for core 1, ISDB-T, ISDB-S
But it seems one DVB adapter device support only ISDB-T or only ISDB-S
if I divide structures. So I define the adapters as the following:
- adapter0: for core 0, ISDB-T
- adapter1: for core 0, ISDB-S
- adapter2: for core 1, ISDB-T
- adapter3: for core 1, ISDB-S
Is this correct?
> ...
> > +static const struct dvb_frontend_ops sc1501a_ops = {
> > + .delsys = { SYS_ISDBS, SYS_ISDBT },
> > + .info = {
> > + .name = "Socionext SC1501A",
> > + .frequency_min = 1032000,
> > + .frequency_max = 770000000,
> > + .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
> > + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
> > + FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
> > + },
> > +
> > + .sleep = sc1501a_sleep,
> > + .set_frontend = sc1501a_set_frontend,
> > + .get_tune_settings = sc1501a_get_tune_settings,
> > + .read_status = sc1501a_read_status,
> > +};
>
> In other words, you'll need to declare two structs here, one for ISDB-T
> and another one for ISDB-S.
>
OK, I'm going to divide this structure for Terrestrial and Satellite. And
add attach functions same as Helene driver.
I'll send v4 patch.
> Yeah, I know that this sucks. If you are in the mood of touching the
> DVB core, I'm willing to consider a patch that would fix this, provided
> that it won't break backward compatibility with other drivers (or would
> convert the other satellite drivers to use the new way).
>
> Thanks,
> Mauro
Hmm, I don't know the details of DVB core, I try to investigate it.
Regards,
--
Katsuhiro Suzuki
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-05 1:58 ` Katsuhiro Suzuki
@ 2018-07-05 2:42 ` Mauro Carvalho Chehab
2018-07-05 5:43 ` Katsuhiro Suzuki
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-05 2:42 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel
Em Thu, 5 Jul 2018 10:58:42 +0900
"Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> Hi Mauro,
>
> > -----Original Message-----
> > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Sent: Thursday, July 5, 2018 1:58 AM
> > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> <masami.hiramatsu@linaro.org>;
> > Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > demodulator driver
> >
> > Hi Katsuhiro-san,
> >
> > Em Thu, 21 Jun 2018 12:17:48 +0900
> > Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> escreveu:
> >
> > > This patch adds a frontend driver for the Socionext SC1501A series
> > > and Socionext MN88443x ISDB-S/T demodulators.
> >
> > Sorry for taking so long to review it. We're missing a sub-maintainer
> > for DVB, with would otherwise speed up reviews of DVB patches.
>
> No problem, thank you for reviewing! I appreciate it.
>
>
> > >
> > > The maximum and minimum frequency of Socionext SC1501A comes from
> > > ISDB-S and ISDB-T so frequency range is the following:
> > > - ISDB-S (BS/CS110 IF frequency in kHz, Local freq 10.678GHz)
> > > - Min: BS-1: 1032000 => 1032.23MHz
> > > - Max: ND24: 2701000 => 2070.25MHz
> > > - ISDB-T (in Hz)
> > > - Min: ch13: 470000000 => 470.357857MHz
> > > - Max: ch62: 770000000 => 769.927857MHz
> >
> > There is actually an error on that part of the driver. Right now,
> > the DVB core expects Satellite frequencies (DVB-S, ISDB-S, ...)
> > in kHz. For all other delivery systems, it is in Hz.
> >
> > It is this way due to historic reasons. While it won't be hard to
> > change the core, that would require to touch all Satellite drivers.
> >
> > As there are very few frontend drivers that accept both Satellite
> > and Terrestrial standards, what we do, instead, is to setup
> > two frontends. See, for example, drivers/media/dvb-frontends/helene.c.
> >
>
> Thank you for describing it. I understand our device is rare case, and
> the reason why Helene has Terrestrial and Satellite structures.
>
> I'm using MN884434 device that has 2 cores. I want to setup DVB adapter
> devices (/dev/dvb/adapter0/*) for our frontend system as the following:
>
> - adapter0: for core 0, ISDB-T, ISDB-S
> - adapter1: for core 1, ISDB-T, ISDB-S
Yeah, that is what it was supposed to work, if the core was ready for it.
> But it seems one DVB adapter device support only ISDB-T or only ISDB-S
> if I divide structures. So I define the adapters as the following:
>
> - adapter0: for core 0, ISDB-T
> - adapter1: for core 0, ISDB-S
> - adapter2: for core 1, ISDB-T
> - adapter3: for core 1, ISDB-S
>
> Is this correct?
That's the way the current driver with uses helene does.
>
>
> > ...
> > > +static const struct dvb_frontend_ops sc1501a_ops = {
> > > + .delsys = { SYS_ISDBS, SYS_ISDBT },
> > > + .info = {
> > > + .name = "Socionext SC1501A",
> > > + .frequency_min = 1032000,
> > > + .frequency_max = 770000000,
> > > + .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
> > > + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
> > > + FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
> > > + },
> > > +
> > > + .sleep = sc1501a_sleep,
> > > + .set_frontend = sc1501a_set_frontend,
> > > + .get_tune_settings = sc1501a_get_tune_settings,
> > > + .read_status = sc1501a_read_status,
> > > +};
> >
> > In other words, you'll need to declare two structs here, one for ISDB-T
> > and another one for ISDB-S.
> >
>
> OK, I'm going to divide this structure for Terrestrial and Satellite. And
> add attach functions same as Helene driver.
>
> I'll send v4 patch.
I ended by writing two patches that should be solving the issues
inside the core. With them[1], it will work the way you want.
There is a catch: you'll need to convert Helene to have a single
entry and be sure that the driver that currently uses it (netup_unidvb)
will keep working. I guess I have one such hardware here for testing.
[1] after tested/reviewed - I didn't test them yet. Feel free to test.
So, please look at the two patches I sent today to the mailing list.
(not sure why, they're taking a long time to arrive there - perhaps
vger has some issues).
I added them on this tree:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_freq_hz
it is the last two patches there:
- https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=b3d63a8f038d136b26692bc3a14554960e767f4a
- https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=2a369e8faf3b277baff4026371f298e95c84fbb2
I'm not sure if all applications will do the right thing, though, as
it will depend if they query the capabilities before or after switching
to a different delivery system. If it get caps before and store them
in Hz, apps will work, but tests are required.
>
>
> > Yeah, I know that this sucks. If you are in the mood of touching the
> > DVB core, I'm willing to consider a patch that would fix this, provided
> > that it won't break backward compatibility with other drivers (or would
> > convert the other satellite drivers to use the new way).
> >
> > Thanks,
> > Mauro
>
> Hmm, I don't know the details of DVB core, I try to investigate it.
>
>
> Regards,
> --
> Katsuhiro Suzuki
>
>
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-05 2:42 ` Mauro Carvalho Chehab
@ 2018-07-05 5:43 ` Katsuhiro Suzuki
2018-07-06 0:27 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-07-05 5:43 UTC (permalink / raw)
To: 'Mauro Carvalho Chehab',
Suzuki, Katsuhiro/鈴木 勝博
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel
Hi Mauro,
Thank you very much! Great works.
Your patches works fine with my driver (modified max/min frequencies).
Tested-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
And I have one question in the below.
> -----Original Message-----
> From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Sent: Thursday, July 5, 2018 11:43 AM
> To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> Cc: linux-media@vger.kernel.org; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> demodulator driver
>
> Em Thu, 5 Jul 2018 10:58:42 +0900
> "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
>
> > Hi Mauro,
> >
> > > -----Original Message-----
> > > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > Sent: Thursday, July 5, 2018 1:58 AM
> > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > <masami.hiramatsu@linaro.org>;
> > > Jassi Brar <jaswinder.singh@linaro.org>;
> linux-arm-kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > demodulator driver
> > >
> > > Hi Katsuhiro-san,
> > >
> > > Em Thu, 21 Jun 2018 12:17:48 +0900
> > > Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> escreveu:
> > >
> > > > This patch adds a frontend driver for the Socionext SC1501A series
> > > > and Socionext MN88443x ISDB-S/T demodulators.
> > >
> > > Sorry for taking so long to review it. We're missing a sub-maintainer
> > > for DVB, with would otherwise speed up reviews of DVB patches.
> >
> > No problem, thank you for reviewing! I appreciate it.
> >
> >
> > > >
> > > > The maximum and minimum frequency of Socionext SC1501A comes from
> > > > ISDB-S and ISDB-T so frequency range is the following:
> > > > - ISDB-S (BS/CS110 IF frequency in kHz, Local freq 10.678GHz)
> > > > - Min: BS-1: 1032000 => 1032.23MHz
> > > > - Max: ND24: 2701000 => 2070.25MHz
> > > > - ISDB-T (in Hz)
> > > > - Min: ch13: 470000000 => 470.357857MHz
> > > > - Max: ch62: 770000000 => 769.927857MHz
> > >
> > > There is actually an error on that part of the driver. Right now,
> > > the DVB core expects Satellite frequencies (DVB-S, ISDB-S, ...)
> > > in kHz. For all other delivery systems, it is in Hz.
> > >
> > > It is this way due to historic reasons. While it won't be hard to
> > > change the core, that would require to touch all Satellite drivers.
> > >
> > > As there are very few frontend drivers that accept both Satellite
> > > and Terrestrial standards, what we do, instead, is to setup
> > > two frontends. See, for example, drivers/media/dvb-frontends/helene.c.
> > >
> >
> > Thank you for describing it. I understand our device is rare case, and
> > the reason why Helene has Terrestrial and Satellite structures.
> >
> > I'm using MN884434 device that has 2 cores. I want to setup DVB adapter
> > devices (/dev/dvb/adapter0/*) for our frontend system as the following:
> >
> > - adapter0: for core 0, ISDB-T, ISDB-S
> > - adapter1: for core 1, ISDB-T, ISDB-S
>
> Yeah, that is what it was supposed to work, if the core was ready for it.
>
> > But it seems one DVB adapter device support only ISDB-T or only ISDB-S
> > if I divide structures. So I define the adapters as the following:
> >
> > - adapter0: for core 0, ISDB-T
> > - adapter1: for core 0, ISDB-S
> > - adapter2: for core 1, ISDB-T
> > - adapter3: for core 1, ISDB-S
> >
> > Is this correct?
>
> That's the way the current driver with uses helene does.
>
> >
> >
> > > ...
> > > > +static const struct dvb_frontend_ops sc1501a_ops = {
> > > > + .delsys = { SYS_ISDBS, SYS_ISDBT },
> > > > + .info = {
> > > > + .name = "Socionext SC1501A",
> > > > + .frequency_min = 1032000,
> > > > + .frequency_max = 770000000,
> > > > + .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
> > > > + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
> > > > + FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
> > > > + },
> > > > +
> > > > + .sleep = sc1501a_sleep,
> > > > + .set_frontend = sc1501a_set_frontend,
> > > > + .get_tune_settings = sc1501a_get_tune_settings,
> > > > + .read_status = sc1501a_read_status,
> > > > +};
> > >
> > > In other words, you'll need to declare two structs here, one for ISDB-T
> > > and another one for ISDB-S.
> > >
> >
> > OK, I'm going to divide this structure for Terrestrial and Satellite. And
> > add attach functions same as Helene driver.
> >
> > I'll send v4 patch.
>
> I ended by writing two patches that should be solving the issues
> inside the core. With them[1], it will work the way you want.
>
> There is a catch: you'll need to convert Helene to have a single
> entry and be sure that the driver that currently uses it (netup_unidvb)
> will keep working. I guess I have one such hardware here for testing.
>
> [1] after tested/reviewed - I didn't test them yet. Feel free to test.
>
Thank you!!
I try to fix '[PATCH v4] media: helene: add I2C device probe function'
patch but I have a question...
My idea is adding new dvb_tuner_ops structure and I2C probe function for
supporting multiple systems. Current drivers (netup) continue to use
helene_attach_t() and helene_attach_s(), so no need to change netup.
It's conservative but prevent the degrade, I think.
Newer added struct dvb_frontend_internal_info has one pair of max/min
frequency. What is the best way to declare the frequency range for
multiple systems?
For example, Helene uses these info for only Ter or Sat freq ranges:
.name = "Sony HELENE Ter tuner",
.frequency_min_hz = 1 * MHz,
.frequency_max_hz = 1200 * MHz,
.frequency_step_hz = 25 * kHz,
.name = "Sony HELENE Sat tuner",
.frequency_min_hz = 500 * MHz,
.frequency_max_hz = 2500 * MHz,
.frequency_step_hz = 1 * MHz,
Is this better to add new info for both system?
.name = "Sony HELENE Sat/Ter tuner",
.frequency_min_hz = 1 * MHz,
.frequency_max_hz = 2500 * MHz,
.frequency_step_hz = 25 * kHz, // Is this correct...?
> So, please look at the two patches I sent today to the mailing list.
>
> (not sure why, they're taking a long time to arrive there - perhaps
> vger has some issues).
>
> I added them on this tree:
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_freq_hz
>
> it is the last two patches there:
> -
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=b3d63
> a8f038d136b26692bc3a14554960e767f4a
> -
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=2a369
> e8faf3b277baff4026371f298e95c84fbb2
>
> I'm not sure if all applications will do the right thing, though, as
> it will depend if they query the capabilities before or after switching
> to a different delivery system. If it get caps before and store them
> in Hz, apps will work, but tests are required.
>
Ah, indeed. You mean,
- Application want to tune Terrestrial system
- Driver is in Satellite system
- Application query max/min frequency
- DVB API returns max/min frequency in 'kHz'
- Some application will get something wrong
(ex. app specific range check)
Unfortunately, I don't know applications that do such scenario.
My test application does not query max/min range...
> >
> >
> > > Yeah, I know that this sucks. If you are in the mood of touching the
> > > DVB core, I'm willing to consider a patch that would fix this, provided
> > > that it won't break backward compatibility with other drivers (or would
> > > convert the other satellite drivers to use the new way).
> > >
> > > Thanks,
> > > Mauro
> >
> > Hmm, I don't know the details of DVB core, I try to investigate it.
> >
> >
> > Regards,
> > --
> > Katsuhiro Suzuki
> >
> >
> >
>
>
>
> Thanks,
> Mauro
Regards,
--
Katsuhiro Suzuki
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-05 5:43 ` Katsuhiro Suzuki
@ 2018-07-06 0:27 ` Mauro Carvalho Chehab
2018-07-06 6:04 ` Katsuhiro Suzuki
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-06 0:27 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Em Thu, 5 Jul 2018 14:43:49 +0900
"Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> Hi Mauro,
>
> Thank you very much! Great works.
> Your patches works fine with my driver (modified max/min frequencies).
Sent a new version of it to the Mailing List.
>
> Tested-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Thanks for testing. I did an update of the patchset at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_freq_hz_v2
and added a third patch to it.
Could you please test it again using the latest version of dvb-fe-tool
from its git tree:
https://git.linuxtv.org/v4l-utils.git/
After compiling/installing, please call it like:
$ dvb-fe-tool -d isdbt
$ dvb-fe-tool
$ dvb-fe-tool -d isdbs
$ dvb-fe-tool
When called without arguments, it will show the frequency range as
reported by FE_GET_INFO (and used internally by the Kernel), e. g.
it will display something like:
$ dvb-fe-tool
Device DiBcom 8000 ISDB-T (/dev/dvb/adapter0/frontend0) capabilities:
CAN_FEC_1_2
CAN_FEC_2_3
CAN_FEC_3_4
CAN_FEC_5_6
CAN_FEC_7_8
CAN_FEC_AUTO
CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO
CAN_INVERSION_AUTO
CAN_QAM_16
CAN_QAM_64
CAN_QAM_AUTO
CAN_QPSK
CAN_RECOVER
CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: ISDBT
Supported delivery system:
[ISDBT]
Frequency range for the current standard:
From: 45.0 MHz
To: 860 MHz
Step: 62.5 kHz
>
>
> And I have one question in the below.
>
>
> > -----Original Message-----
> > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Sent: Thursday, July 5, 2018 11:43 AM
> > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > Cc: linux-media@vger.kernel.org; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> > Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > demodulator driver
> >
> > Em Thu, 5 Jul 2018 10:58:42 +0900
> > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> >
> > > Hi Mauro,
> > >
> > > > -----Original Message-----
> > > > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > > Sent: Thursday, July 5, 2018 1:58 AM
> > > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > > <masami.hiramatsu@linaro.org>;
> > > > Jassi Brar <jaswinder.singh@linaro.org>;
> > linux-arm-kernel@lists.infradead.org;
> > > > linux-kernel@vger.kernel.org
> > > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > > demodulator driver
> > > >
> > > > Hi Katsuhiro-san,
> > > >
> > > > Em Thu, 21 Jun 2018 12:17:48 +0900
> > > > Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> escreveu:
> > > >
> > > > > This patch adds a frontend driver for the Socionext SC1501A series
> > > > > and Socionext MN88443x ISDB-S/T demodulators.
> > > >
> > > > Sorry for taking so long to review it. We're missing a sub-maintainer
> > > > for DVB, with would otherwise speed up reviews of DVB patches.
> > >
> > > No problem, thank you for reviewing! I appreciate it.
> > >
> > >
> > > > >
> > > > > The maximum and minimum frequency of Socionext SC1501A comes from
> > > > > ISDB-S and ISDB-T so frequency range is the following:
> > > > > - ISDB-S (BS/CS110 IF frequency in kHz, Local freq 10.678GHz)
> > > > > - Min: BS-1: 1032000 => 1032.23MHz
> > > > > - Max: ND24: 2701000 => 2070.25MHz
> > > > > - ISDB-T (in Hz)
> > > > > - Min: ch13: 470000000 => 470.357857MHz
> > > > > - Max: ch62: 770000000 => 769.927857MHz
> > > >
> > > > There is actually an error on that part of the driver. Right now,
> > > > the DVB core expects Satellite frequencies (DVB-S, ISDB-S, ...)
> > > > in kHz. For all other delivery systems, it is in Hz.
> > > >
> > > > It is this way due to historic reasons. While it won't be hard to
> > > > change the core, that would require to touch all Satellite drivers.
> > > >
> > > > As there are very few frontend drivers that accept both Satellite
> > > > and Terrestrial standards, what we do, instead, is to setup
> > > > two frontends. See, for example, drivers/media/dvb-frontends/helene.c.
> > > >
> > >
> > > Thank you for describing it. I understand our device is rare case, and
> > > the reason why Helene has Terrestrial and Satellite structures.
> > >
> > > I'm using MN884434 device that has 2 cores. I want to setup DVB adapter
> > > devices (/dev/dvb/adapter0/*) for our frontend system as the following:
> > >
> > > - adapter0: for core 0, ISDB-T, ISDB-S
> > > - adapter1: for core 1, ISDB-T, ISDB-S
> >
> > Yeah, that is what it was supposed to work, if the core was ready for it.
> >
> > > But it seems one DVB adapter device support only ISDB-T or only ISDB-S
> > > if I divide structures. So I define the adapters as the following:
> > >
> > > - adapter0: for core 0, ISDB-T
> > > - adapter1: for core 0, ISDB-S
> > > - adapter2: for core 1, ISDB-T
> > > - adapter3: for core 1, ISDB-S
> > >
> > > Is this correct?
> >
> > That's the way the current driver with uses helene does.
> >
> > >
> > >
> > > > ...
> > > > > +static const struct dvb_frontend_ops sc1501a_ops = {
> > > > > + .delsys = { SYS_ISDBS, SYS_ISDBT },
> > > > > + .info = {
> > > > > + .name = "Socionext SC1501A",
> > > > > + .frequency_min = 1032000,
> > > > > + .frequency_max = 770000000,
> > > > > + .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
> > > > > + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
> > > > > + FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
> > > > > + },
> > > > > +
> > > > > + .sleep = sc1501a_sleep,
> > > > > + .set_frontend = sc1501a_set_frontend,
> > > > > + .get_tune_settings = sc1501a_get_tune_settings,
> > > > > + .read_status = sc1501a_read_status,
> > > > > +};
> > > >
> > > > In other words, you'll need to declare two structs here, one for ISDB-T
> > > > and another one for ISDB-S.
> > > >
> > >
> > > OK, I'm going to divide this structure for Terrestrial and Satellite. And
> > > add attach functions same as Helene driver.
> > >
> > > I'll send v4 patch.
> >
> > I ended by writing two patches that should be solving the issues
> > inside the core. With them[1], it will work the way you want.
> >
> > There is a catch: you'll need to convert Helene to have a single
> > entry and be sure that the driver that currently uses it (netup_unidvb)
> > will keep working. I guess I have one such hardware here for testing.
> >
> > [1] after tested/reviewed - I didn't test them yet. Feel free to test.
> >
>
> Thank you!!
>
> I try to fix '[PATCH v4] media: helene: add I2C device probe function'
> patch but I have a question...
>
> My idea is adding new dvb_tuner_ops structure and I2C probe function for
> supporting multiple systems. Current drivers (netup) continue to use
> helene_attach_t() and helene_attach_s(), so no need to change netup.
> It's conservative but prevent the degrade, I think.
Works for me.
>
> Newer added struct dvb_frontend_internal_info has one pair of max/min
> frequency. What is the best way to declare the frequency range for
> multiple systems?
>
> For example, Helene uses these info for only Ter or Sat freq ranges:
>
> .name = "Sony HELENE Ter tuner",
> .frequency_min_hz = 1 * MHz,
> .frequency_max_hz = 1200 * MHz,
> .frequency_step_hz = 25 * kHz,
>
> .name = "Sony HELENE Sat tuner",
> .frequency_min_hz = 500 * MHz,
> .frequency_max_hz = 2500 * MHz,
> .frequency_step_hz = 1 * MHz,
>
> Is this better to add new info for both system?
>
> .name = "Sony HELENE Sat/Ter tuner",
> .frequency_min_hz = 1 * MHz,
> .frequency_max_hz = 2500 * MHz,
> .frequency_step_hz = 25 * kHz, // Is this correct...?
That is indeed a very good question, and maybe a reason why we
may need other approaches.
See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
the frequency range should be ok. It would aget_frontend_algoctually be pretty cool
to use a tuner with such wide range for SDR, if the hardware supports
raw I/Q collect :-D
The frequency step is a different issue. If the tuner driver uses
DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
this function is not defined), then the step will be used to adjust
the zigzag interactions. If it is too small, the tuning will lose
channels if the signal is not strong.
In the specific case of helene, it doesn't have a get_frontend_algo,
so it will use the step frequency.
I'm not sure how to solve this issue. Maybe Abylay may shed a light
here, if helene does sigzag in hardware or not.
If it does in hardware, you could add a get_frontend_algo() routine
at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
algorithm in the Kernel will stop, as it will rely at the hardware.
Please notice that, if the hardware doesn't do zigzag itself, this
will make it lose channels. On the other hand, if the hardware does
have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
Kernel won't try to do sigzag itself.
>
>
> > So, please look at the two patches I sent today to the mailing list.
> >
> > (not sure why, they're taking a long time to arrive there - perhaps
> > vger has some issues).
> >
> > I added them on this tree:
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_freq_hz
> >
> > it is the last two patches there:
> > -
> > https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=b3d63
> > a8f038d136b26692bc3a14554960e767f4a
> > -
> > https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=2a369
> > e8faf3b277baff4026371f298e95c84fbb2
> >
> > I'm not sure if all applications will do the right thing, though, as
> > it will depend if they query the capabilities before or after switching
> > to a different delivery system. If it get caps before and store them
> > in Hz, apps will work, but tests are required.
> >
>
> Ah, indeed. You mean,
>
> - Application want to tune Terrestrial system
> - Driver is in Satellite system
> - Application query max/min frequency
> - DVB API returns max/min frequency in 'kHz'
> - Some application will get something wrong
> (ex. app specific range check)
Yes. I guess, however, that most apps won't do range checks themselves,
but this has yet to be checked.
> Unfortunately, I don't know applications that do such scenario.
> My test application does not query max/min range...
>
>
> > >
> > >
> > > > Yeah, I know that this sucks. If you are in the mood of touching the
> > > > DVB core, I'm willing to consider a patch that would fix this, provided
> > > > that it won't break backward compatibility with other drivers (or would
> > > > convert the other satellite drivers to use the new way).
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > Hmm, I don't know the details of DVB core, I try to investigate it.
> > >
> > >
> > > Regards,
> > > --
> > > Katsuhiro Suzuki
> > >
> > >
> > >
> >
> >
> >
> > Thanks,
> > Mauro
>
>
> Regards,
> --
> Katsuhiro Suzuki
>
>
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-06 0:27 ` Mauro Carvalho Chehab
@ 2018-07-06 6:04 ` Katsuhiro Suzuki
2018-07-06 11:16 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-07-06 6:04 UTC (permalink / raw)
To: 'Mauro Carvalho Chehab',
Suzuki, Katsuhiro/鈴木 勝博
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Hello Mauro,
Thank you for new patches, it works fine.
Detail log is the below:
> -----Original Message-----
> From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Sent: Friday, July 6, 2018 9:27 AM
> To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> Cc: linux-media@vger.kernel.org; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> demodulator driver
>
> Em Thu, 5 Jul 2018 14:43:49 +0900
> "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
>
> > Hi Mauro,
> >
> > Thank you very much! Great works.
> > Your patches works fine with my driver (modified max/min frequencies).
>
> Sent a new version of it to the Mailing List.
>
> >
> > Tested-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
>
> Thanks for testing. I did an update of the patchset at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_freq_hz_v2
>
> and added a third patch to it.
>
>
> Could you please test it again using the latest version of dvb-fe-tool
> from its git tree:
>
> https://git.linuxtv.org/v4l-utils.git/
>
> After compiling/installing, please call it like:
>
> $ dvb-fe-tool -d isdbt
> $ dvb-fe-tool
> $ dvb-fe-tool -d isdbs
> $ dvb-fe-tool
>
> When called without arguments, it will show the frequency range as
> reported by FE_GET_INFO (and used internally by the Kernel), e. g.
> it will display something like:
>
> $ dvb-fe-tool
> Device DiBcom 8000 ISDB-T (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_FEC_1_2
> CAN_FEC_2_3
> CAN_FEC_3_4
> CAN_FEC_5_6
> CAN_FEC_7_8
> CAN_FEC_AUTO
> CAN_GUARD_INTERVAL_AUTO
> CAN_HIERARCHY_AUTO
> CAN_INVERSION_AUTO
> CAN_QAM_16
> CAN_QAM_64
> CAN_QAM_AUTO
> CAN_QPSK
> CAN_RECOVER
> CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.11, Current v5 delivery system: ISDBT
> Supported delivery system:
> [ISDBT]
> Frequency range for the current standard:
> From: 45.0 MHz
> To: 860 MHz
> Step: 62.5 kHz
>
Here is the log of dvb-fe-tool on my environment.
--------------------
# ./utils/dvb/.libs/dvb-fe-tool -d isdbs
Changing delivery system to: ISDBS
ERROR FE_SET_VOLTAGE: Unknown error 524
# ./utils/dvb/.libs/dvb-fe-tool
Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
CAN_FEC_AUTO
CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO
CAN_INVERSION_AUTO
CAN_QAM_AUTO
CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: ISDBS
Supported delivery systems:
[ISDBS]
ISDBT
Frequency range for the current standard:
From: 470 MHz
To: 2.07 GHz
Step: 25.0 kHz
Symbol rate ranges for the current standard:
From: 0Bauds
To: 0Bauds
SEC: set voltage to OFF
ERROR FE_SET_VOLTAGE: Operation not permitted
# ./utils/dvb/.libs/dvb-fe-tool -d isdbt
Changing delivery system to: ISDBT
ERROR FE_SET_VOLTAGE: Unknown error 524
# ./utils/dvb/.libs/dvb-fe-tool
Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
CAN_FEC_AUTO
CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO
CAN_INVERSION_AUTO
CAN_QAM_AUTO
CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: ISDBT
Supported delivery systems:
ISDBS
[ISDBT]
Frequency range for the current standard:
From: 470 MHz
To: 2.07 GHz
Step: 25.0 kHz
----------
>
> >
> >
> > And I have one question in the below.
> >
> >
> > > -----Original Message-----
> > > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > Sent: Thursday, July 5, 2018 11:43 AM
> > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> <masami.hiramatsu@linaro.org>;
> > > Jassi Brar <jaswinder.singh@linaro.org>;
> linux-arm-kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > demodulator driver
> > >
> > > Em Thu, 5 Jul 2018 10:58:42 +0900
> > > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> > >
> > > > Hi Mauro,
> > > >
> > > > > -----Original Message-----
> > > > > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > > > Sent: Thursday, July 5, 2018 1:58 AM
> > > > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > > > <masami.hiramatsu@linaro.org>;
> > > > > Jassi Brar <jaswinder.singh@linaro.org>;
> > > linux-arm-kernel@lists.infradead.org;
> > > > > linux-kernel@vger.kernel.org
> > > > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > > > demodulator driver
> > > > >
> > > > > Hi Katsuhiro-san,
> > > > >
> > > > > Em Thu, 21 Jun 2018 12:17:48 +0900
> > > > > Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> escreveu:
> > > > >
> > > > > > This patch adds a frontend driver for the Socionext SC1501A series
> > > > > > and Socionext MN88443x ISDB-S/T demodulators.
> > > > >
> > > > > Sorry for taking so long to review it. We're missing a sub-maintainer
> > > > > for DVB, with would otherwise speed up reviews of DVB patches.
> > > >
> > > > No problem, thank you for reviewing! I appreciate it.
> > > >
> > > >
> > > > > >
> > > > > > The maximum and minimum frequency of Socionext SC1501A comes from
> > > > > > ISDB-S and ISDB-T so frequency range is the following:
> > > > > > - ISDB-S (BS/CS110 IF frequency in kHz, Local freq 10.678GHz)
> > > > > > - Min: BS-1: 1032000 => 1032.23MHz
> > > > > > - Max: ND24: 2701000 => 2070.25MHz
> > > > > > - ISDB-T (in Hz)
> > > > > > - Min: ch13: 470000000 => 470.357857MHz
> > > > > > - Max: ch62: 770000000 => 769.927857MHz
> > > > >
> > > > > There is actually an error on that part of the driver. Right now,
> > > > > the DVB core expects Satellite frequencies (DVB-S, ISDB-S, ...)
> > > > > in kHz. For all other delivery systems, it is in Hz.
> > > > >
> > > > > It is this way due to historic reasons. While it won't be hard to
> > > > > change the core, that would require to touch all Satellite drivers.
> > > > >
> > > > > As there are very few frontend drivers that accept both Satellite
> > > > > and Terrestrial standards, what we do, instead, is to setup
> > > > > two frontends. See, for example, drivers/media/dvb-frontends/helene.c.
> > > > >
> > > >
> > > > Thank you for describing it. I understand our device is rare case, and
> > > > the reason why Helene has Terrestrial and Satellite structures.
> > > >
> > > > I'm using MN884434 device that has 2 cores. I want to setup DVB adapter
> > > > devices (/dev/dvb/adapter0/*) for our frontend system as the following:
> > > >
> > > > - adapter0: for core 0, ISDB-T, ISDB-S
> > > > - adapter1: for core 1, ISDB-T, ISDB-S
> > >
> > > Yeah, that is what it was supposed to work, if the core was ready for it.
> > >
> > > > But it seems one DVB adapter device support only ISDB-T or only ISDB-S
> > > > if I divide structures. So I define the adapters as the following:
> > > >
> > > > - adapter0: for core 0, ISDB-T
> > > > - adapter1: for core 0, ISDB-S
> > > > - adapter2: for core 1, ISDB-T
> > > > - adapter3: for core 1, ISDB-S
> > > >
> > > > Is this correct?
> > >
> > > That's the way the current driver with uses helene does.
> > >
> > > >
> > > >
> > > > > ...
> > > > > > +static const struct dvb_frontend_ops sc1501a_ops = {
> > > > > > + .delsys = { SYS_ISDBS, SYS_ISDBT },
> > > > > > + .info = {
> > > > > > + .name = "Socionext SC1501A",
> > > > > > + .frequency_min = 1032000,
> > > > > > + .frequency_max = 770000000,
> > > > > > + .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
> > > > > > + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
> > > > > > + FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
> > > > > > + },
> > > > > > +
> > > > > > + .sleep = sc1501a_sleep,
> > > > > > + .set_frontend = sc1501a_set_frontend,
> > > > > > + .get_tune_settings = sc1501a_get_tune_settings,
> > > > > > + .read_status = sc1501a_read_status,
> > > > > > +};
> > > > >
> > > > > In other words, you'll need to declare two structs here, one for ISDB-T
> > > > > and another one for ISDB-S.
> > > > >
> > > >
> > > > OK, I'm going to divide this structure for Terrestrial and Satellite. And
> > > > add attach functions same as Helene driver.
> > > >
> > > > I'll send v4 patch.
> > >
> > > I ended by writing two patches that should be solving the issues
> > > inside the core. With them[1], it will work the way you want.
> > >
> > > There is a catch: you'll need to convert Helene to have a single
> > > entry and be sure that the driver that currently uses it (netup_unidvb)
> > > will keep working. I guess I have one such hardware here for testing.
> > >
> > > [1] after tested/reviewed - I didn't test them yet. Feel free to test.
> > >
> >
> > Thank you!!
> >
> > I try to fix '[PATCH v4] media: helene: add I2C device probe function'
> > patch but I have a question...
> >
> > My idea is adding new dvb_tuner_ops structure and I2C probe function for
> > supporting multiple systems. Current drivers (netup) continue to use
> > helene_attach_t() and helene_attach_s(), so no need to change netup.
> > It's conservative but prevent the degrade, I think.
>
> Works for me.
>
> >
> > Newer added struct dvb_frontend_internal_info has one pair of max/min
> > frequency. What is the best way to declare the frequency range for
> > multiple systems?
> >
> > For example, Helene uses these info for only Ter or Sat freq ranges:
> >
> > .name = "Sony HELENE Ter tuner",
> > .frequency_min_hz = 1 * MHz,
> > .frequency_max_hz = 1200 * MHz,
> > .frequency_step_hz = 25 * kHz,
> >
> > .name = "Sony HELENE Sat tuner",
> > .frequency_min_hz = 500 * MHz,
> > .frequency_max_hz = 2500 * MHz,
> > .frequency_step_hz = 1 * MHz,
> >
> > Is this better to add new info for both system?
> >
> > .name = "Sony HELENE Sat/Ter tuner",
> > .frequency_min_hz = 1 * MHz,
> > .frequency_max_hz = 2500 * MHz,
> > .frequency_step_hz = 25 * kHz, // Is this correct...?
>
> That is indeed a very good question, and maybe a reason why we
> may need other approaches.
>
> See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> the frequency range should be ok. It would aget_frontend_algoctually be pretty cool
> to use a tuner with such wide range for SDR, if the hardware supports
> raw I/Q collect :-D
>
> The frequency step is a different issue. If the tuner driver uses
> DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> this function is not defined), then the step will be used to adjust
> the zigzag interactions. If it is too small, the tuning will lose
> channels if the signal is not strong.
>
Thank you for describing. It's difficult problem...
> In the specific case of helene, it doesn't have a get_frontend_algo,
> so it will use the step frequency.
>
> I'm not sure how to solve this issue. Maybe Abylay may shed a light
> here, if helene does sigzag in hardware or not.
>
As far as I know, Helene does not have automatic scan mechanism in
hardware.
> If it does in hardware, you could add a get_frontend_algo() routine
> at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> algorithm in the Kernel will stop, as it will rely at the hardware.
>
> Please notice that, if the hardware doesn't do zigzag itself, this
> will make it lose channels. On the other hand, if the hardware does
> have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> Kernel won't try to do sigzag itself.
>
ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
ISDB-T system and 25kHz is small for ISDB-S system.
I cannot decide fixed step size for supporting multiple systems. So I
think it's prefer to select the suitable step size at giving the
delivery system (in set_frontend() callback or some others).
> >
> >
> > > So, please look at the two patches I sent today to the mailing list.
> > >
> > > (not sure why, they're taking a long time to arrive there - perhaps
> > > vger has some issues).
> > >
> > > I added them on this tree:
> > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_freq_hz
> > >
> > > it is the last two patches there:
> > > -
> > >
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=b3d63
> > > a8f038d136b26692bc3a14554960e767f4a
> > > -
> > >
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dvb_freq_hz&id=2a369
> > > e8faf3b277baff4026371f298e95c84fbb2
> > >
> > > I'm not sure if all applications will do the right thing, though, as
> > > it will depend if they query the capabilities before or after switching
> > > to a different delivery system. If it get caps before and store them
> > > in Hz, apps will work, but tests are required.
> > >
> >
> > Ah, indeed. You mean,
> >
> > - Application want to tune Terrestrial system
> > - Driver is in Satellite system
> > - Application query max/min frequency
> > - DVB API returns max/min frequency in 'kHz'
> > - Some application will get something wrong
> > (ex. app specific range check)
>
> Yes. I guess, however, that most apps won't do range checks themselves,
> but this has yet to be checked.
>
I think & hope so too...
Regards,
--
Katsuhiro Suzuki
> > Unfortunately, I don't know applications that do such scenario.
> > My test application does not query max/min range...
> >
> >
> > > >
> > > >
> > > > > Yeah, I know that this sucks. If you are in the mood of touching the
> > > > > DVB core, I'm willing to consider a patch that would fix this, provided
> > > > > that it won't break backward compatibility with other drivers (or would
> > > > > convert the other satellite drivers to use the new way).
> > > > >
> > > > > Thanks,
> > > > > Mauro
> > > >
> > > > Hmm, I don't know the details of DVB core, I try to investigate it.
> > > >
> > > >
> > > > Regards,
> > > > --
> > > > Katsuhiro Suzuki
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Thanks,
> > > Mauro
> >
> >
> > Regards,
> > --
> > Katsuhiro Suzuki
> >
> >
> >
>
>
>
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-06 6:04 ` Katsuhiro Suzuki
@ 2018-07-06 11:16 ` Mauro Carvalho Chehab
2018-07-09 2:04 ` Katsuhiro Suzuki
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-06 11:16 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Em Fri, 6 Jul 2018 15:04:08 +0900
"Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> Here is the log of dvb-fe-tool on my environment.
>
> --------------------
> # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> Changing delivery system to: ISDBS
> ERROR FE_SET_VOLTAGE: Unknown error 524
Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
LNBf?
Anyway, I changed the error print message to be clearer, displaying
instead:
ERROR FE_SET_VOLTAGE: driver doesn't support it!
>
> # ./utils/dvb/.libs/dvb-fe-tool
> Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_FEC_AUTO
> CAN_GUARD_INTERVAL_AUTO
> CAN_HIERARCHY_AUTO
> CAN_INVERSION_AUTO
> CAN_QAM_AUTO
> CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.11, Current v5 delivery system: ISDBS
> Supported delivery systems:
> [ISDBS]
> ISDBT
> Frequency range for the current standard:
> From: 470 MHz
> To: 2.07 GHz
> Step: 25.0 kHz
> Symbol rate ranges for the current standard:
> From: 0Bauds
> To: 0Bauds
That seems a driver issue. The ISDB-S ops.info should be
filling both symbol_rate_min and symbol_rate_max.
I suspect that both should be filled with 28860000.
The dvb_frontend.c core might hardcode it, but, IMHO,
it is better to keep those information inside the
tuner/frontend ops.info.
> SEC: set voltage to OFF
> ERROR FE_SET_VOLTAGE: Operation not permitted
>
>
> # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> Changing delivery system to: ISDBT
> ERROR FE_SET_VOLTAGE: Unknown error 524
>
> # ./utils/dvb/.libs/dvb-fe-tool
> Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_FEC_AUTO
> CAN_GUARD_INTERVAL_AUTO
> CAN_HIERARCHY_AUTO
> CAN_INVERSION_AUTO
> CAN_QAM_AUTO
> CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.11, Current v5 delivery system: ISDBT
> Supported delivery systems:
> ISDBS
> [ISDBT]
> Frequency range for the current standard:
> From: 470 MHz
> To: 2.07 GHz
> Step: 25.0 kHz
The rest looks OK for me.
> > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > >
> > > .name = "Sony HELENE Ter tuner",
> > > .frequency_min_hz = 1 * MHz,
> > > .frequency_max_hz = 1200 * MHz,
> > > .frequency_step_hz = 25 * kHz,
> > >
> > > .name = "Sony HELENE Sat tuner",
> > > .frequency_min_hz = 500 * MHz,
> > > .frequency_max_hz = 2500 * MHz,
> > > .frequency_step_hz = 1 * MHz,
> > >
> > > Is this better to add new info for both system?
> > >
> > > .name = "Sony HELENE Sat/Ter tuner",
> > > .frequency_min_hz = 1 * MHz,
> > > .frequency_max_hz = 2500 * MHz,
> > > .frequency_step_hz = 25 * kHz, // Is this correct...?
> >
> > That is indeed a very good question, and maybe a reason why we
> > may need other approaches.
> >
> > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > the frequency range should be ok. It would aget_frontend_algoctually be pretty cool
> > to use a tuner with such wide range for SDR, if the hardware supports
> > raw I/Q collect :-D
> >
> > The frequency step is a different issue. If the tuner driver uses
> > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > this function is not defined), then the step will be used to adjust
> > the zigzag interactions. If it is too small, the tuning will lose
> > channels if the signal is not strong.
> >
>
> Thank you for describing. It's difficult problem...
I double-checked the implementation. We don't need to worry about
zigzag, provided that the ISDB-S implementation at the core is correct.
For satellite/cable standards, the zigzag logic takes the symbol
rate into account, and not the stepsize:
case SYS_DVBS:
case SYS_DVBS2:
case SYS_ISDBS:
case SYS_TURBO:
case SYS_DVBC_ANNEX_A:
case SYS_DVBC_ANNEX_C:
fepriv->min_delay = HZ / 20;
fepriv->step_size = c->symbol_rate / 16000;
fepriv->max_drift = c->symbol_rate / 2000;
break;
For terrestrial standards, it uses the stepsize:
case SYS_DVBT:
case SYS_DVBT2:
case SYS_ISDBT:
case SYS_DTMB:
fepriv->min_delay = HZ / 20;
fepriv->step_size = dvb_frontend_get_stepsize(fe) * 2;
fepriv->max_drift = (dvb_frontend_get_stepsize(fe) * 2) + 1;
break;
So, having a value of 25 kHz there won't affect the zigzag algorithm
for ISDB-S, as it will be used only for ISDB-T.
> > In the specific case of helene, it doesn't have a get_frontend_algo,
> > so it will use the step frequency.
> >
> > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > here, if helene does sigzag in hardware or not.
> >
>
> As far as I know, Helene does not have automatic scan mechanism in
> hardware.
Ok, so the driver is doing the right thing here.
> > If it does in hardware, you could add a get_frontend_algo() routine
> > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > algorithm in the Kernel will stop, as it will rely at the hardware.
> >
> > Please notice that, if the hardware doesn't do zigzag itself, this
> > will make it lose channels. On the other hand, if the hardware does
> > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > Kernel won't try to do sigzag itself.
> >
>
> ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> ISDB-T system and 25kHz is small for ISDB-S system.
Yeah, but, after double-checking the logic, for ISDB-S, it will
use:
c->symbol_rate = 28860000;
c->rolloff = ROLLOFF_35;
c->bandwidth_hz = c->symbol_rate / 100 * 135;
That would actually set the ISDB-S channel separation to 38.961 MHz.
By setting symbol_rate like that, the zigzag for ISDB-S will
be defined by:
fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000 = .002435 - e. g. steps of ~25 kHz */
fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000 = .0194805 - e. g. max drift of ~195 kHz */
Funny enough, it will be using about 25 kHz as step size for ISDB-S.
I have no idea if the ISDB-S standard defines the zigzag logic,
but I would be expecting a higher value for it. So, perhaps
the ISDB-S zigzag could be optimized.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-06 11:16 ` Mauro Carvalho Chehab
@ 2018-07-09 2:04 ` Katsuhiro Suzuki
2018-07-09 13:59 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-07-09 2:04 UTC (permalink / raw)
To: 'Mauro Carvalho Chehab',
Suzuki, Katsuhiro/鈴木 勝博
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Hello Mauro,
> -----Original Message-----
> From: linux-media-owner@vger.kernel.org <linux-media-owner@vger.kernel.org> On
> Behalf Of Mauro Carvalho Chehab
> Sent: Friday, July 6, 2018 8:16 PM
> To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> Cc: linux-media@vger.kernel.org; Masami Hiramatsu
<masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> demodulator driver
>
> Em Fri, 6 Jul 2018 15:04:08 +0900
> "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
>
> > Here is the log of dvb-fe-tool on my environment.
> >
> > --------------------
> > # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> > Changing delivery system to: ISDBS
> > ERROR FE_SET_VOLTAGE: Unknown error 524
>
> Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
> LNBf?
Ah, maybe it's not implemented yet in Helene driver.
>
> Anyway, I changed the error print message to be clearer, displaying
> instead:
>
> ERROR FE_SET_VOLTAGE: driver doesn't support it!
>
It's nice for users. Thanks!
> >
> > # ./utils/dvb/.libs/dvb-fe-tool
> > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > CAN_FEC_AUTO
> > CAN_GUARD_INTERVAL_AUTO
> > CAN_HIERARCHY_AUTO
> > CAN_INVERSION_AUTO
> > CAN_QAM_AUTO
> > CAN_TRANSMISSION_MODE_AUTO
> > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > Supported delivery systems:
> > [ISDBS]
> > ISDBT
> > Frequency range for the current standard:
> > From: 470 MHz
> > To: 2.07 GHz
> > Step: 25.0 kHz
> > Symbol rate ranges for the current standard:
> > From: 0Bauds
> > To: 0Bauds
>
> That seems a driver issue. The ISDB-S ops.info should be
> filling both symbol_rate_min and symbol_rate_max.
>
> I suspect that both should be filled with 28860000.
>
> The dvb_frontend.c core might hardcode it, but, IMHO,
> it is better to keep those information inside the
> tuner/frontend ops.info.
>
Indeed, thank you for reviewing. I fixed my driver. It seems works fine.
----
# utils/dvb/.libs/dvb-fe-tool -a 0
Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
CAN_FEC_AUTO
CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO
CAN_INVERSION_AUTO
CAN_QAM_AUTO
CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: ISDBS
Supported delivery systems:
[ISDBS]
ISDBT
Frequency range for the current standard:
From: 470 MHz
To: 2.07 GHz
Step: 25.0 kHz
Symbol rate ranges for the current standard:
From: 28.9 MBauds
To: 28.9 MBauds
SEC: set voltage to OFF
ERROR FE_SET_VOLTAGE: Operation not permitted
----
> > SEC: set voltage to OFF
> > ERROR FE_SET_VOLTAGE: Operation not permitted
> >
> >
> > # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> > Changing delivery system to: ISDBT
> > ERROR FE_SET_VOLTAGE: Unknown error 524
> >
> > # ./utils/dvb/.libs/dvb-fe-tool
> > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > CAN_FEC_AUTO
> > CAN_GUARD_INTERVAL_AUTO
> > CAN_HIERARCHY_AUTO
> > CAN_INVERSION_AUTO
> > CAN_QAM_AUTO
> > CAN_TRANSMISSION_MODE_AUTO
> > DVB API Version 5.11, Current v5 delivery system: ISDBT
> > Supported delivery systems:
> > ISDBS
> > [ISDBT]
> > Frequency range for the current standard:
> > From: 470 MHz
> > To: 2.07 GHz
> > Step: 25.0 kHz
>
> The rest looks OK for me.
>
> > > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > > >
> > > > .name = "Sony HELENE Ter tuner",
> > > > .frequency_min_hz = 1 * MHz,
> > > > .frequency_max_hz = 1200 * MHz,
> > > > .frequency_step_hz = 25 * kHz,
> > > >
> > > > .name = "Sony HELENE Sat tuner",
> > > > .frequency_min_hz = 500 * MHz,
> > > > .frequency_max_hz = 2500 * MHz,
> > > > .frequency_step_hz = 1 * MHz,
> > > >
> > > > Is this better to add new info for both system?
> > > >
> > > > .name = "Sony HELENE Sat/Ter tuner",
> > > > .frequency_min_hz = 1 * MHz,
> > > > .frequency_max_hz = 2500 * MHz,
> > > > .frequency_step_hz = 25 * kHz, // Is this correct...?
> > >
> > > That is indeed a very good question, and maybe a reason why we
> > > may need other approaches.
> > >
> > > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > > the frequency range should be ok. It would aget_frontend_algoctually be
pretty
> cool
> > > to use a tuner with such wide range for SDR, if the hardware supports
> > > raw I/Q collect :-D
> > >
> > > The frequency step is a different issue. If the tuner driver uses
> > > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > > this function is not defined), then the step will be used to adjust
> > > the zigzag interactions. If it is too small, the tuning will lose
> > > channels if the signal is not strong.
> > >
> >
> > Thank you for describing. It's difficult problem...
>
> I double-checked the implementation. We don't need to worry about
> zigzag, provided that the ISDB-S implementation at the core is correct.
>
> For satellite/cable standards, the zigzag logic takes the symbol
> rate into account, and not the stepsize:
>
> case SYS_DVBS:
> case SYS_DVBS2:
> case SYS_ISDBS:
> case SYS_TURBO:
> case SYS_DVBC_ANNEX_A:
> case SYS_DVBC_ANNEX_C:
> fepriv->min_delay = HZ / 20;
> fepriv->step_size = c->symbol_rate / 16000;
> fepriv->max_drift = c->symbol_rate / 2000;
> break;
>
> For terrestrial standards, it uses the stepsize:
>
> case SYS_DVBT:
> case SYS_DVBT2:
> case SYS_ISDBT:
> case SYS_DTMB:
> fepriv->min_delay = HZ / 20;
> fepriv->step_size = dvb_frontend_get_stepsize(fe) * 2;
> fepriv->max_drift = (dvb_frontend_get_stepsize(fe) * 2)
+
> 1;
> break;
>
> So, having a value of 25 kHz there won't affect the zigzag algorithm
> for ISDB-S, as it will be used only for ISDB-T.
>
Thank you for checking and describing. I checked it too.
Default value is fine as you said, and we can use get_tune_settings()
callback if we face the problem or need different settings for each
delivery systems in the future.
/* get frontend-specific tuning settings */
memset(&fetunesettings, 0, sizeof(struct dvb_frontend_tune_settings));
if (fe->ops.get_tune_settings && (fe->ops.get_tune_settings(fe,
&fetunesettings) == 0)) {
fepriv->min_delay = (fetunesettings.min_delay_ms * HZ) / 1000;
fepriv->max_drift = fetunesettings.max_drift;
fepriv->step_size = fetunesettings.step_size;
} else {
/* default values */
...
> > > In the specific case of helene, it doesn't have a get_frontend_algo,
> > > so it will use the step frequency.
> > >
> > > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > > here, if helene does sigzag in hardware or not.
> > >
> >
> > As far as I know, Helene does not have automatic scan mechanism in
> > hardware.
>
> Ok, so the driver is doing the right thing here.
>
> > > If it does in hardware, you could add a get_frontend_algo() routine
> > > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > > algorithm in the Kernel will stop, as it will rely at the hardware.
> > >
> > > Please notice that, if the hardware doesn't do zigzag itself, this
> > > will make it lose channels. On the other hand, if the hardware does
> > > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > > Kernel won't try to do sigzag itself.
> > >
> >
> > ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> > BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> > ISDB-T system and 25kHz is small for ISDB-S system.
>
> Yeah, but, after double-checking the logic, for ISDB-S, it will
> use:
>
> c->symbol_rate = 28860000;
> c->rolloff = ROLLOFF_35;
> c->bandwidth_hz = c->symbol_rate / 100 * 135;
>
> That would actually set the ISDB-S channel separation to 38.961 MHz.
>
> By setting symbol_rate like that, the zigzag for ISDB-S will
> be defined by:
>
> fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000 =
.002435
> - e. g. steps of ~25 kHz */
> fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000 =
.0194805
> - e. g. max drift of ~195 kHz */
>
> Funny enough, it will be using about 25 kHz as step size for ISDB-S.
>
> I have no idea if the ISDB-S standard defines the zigzag logic,
> but I would be expecting a higher value for it. So, perhaps
> the ISDB-S zigzag could be optimized.
>
> Thanks,
> Mauro
Hmm, interesting. I don't know zigzag for ISDB-S too, sorry...
Anyway, I don't worry about that. I said in above, we can use
get_tune_settings() for fine tuning.
Regards,
--
Katsuhiro Suzuki
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-09 2:04 ` Katsuhiro Suzuki
@ 2018-07-09 13:59 ` Mauro Carvalho Chehab
2018-07-10 2:50 ` Katsuhiro Suzuki
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-09 13:59 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Em Mon, 9 Jul 2018 11:04:36 +0900
"Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> Hello Mauro,
>
> > -----Original Message-----
> > From: linux-media-owner@vger.kernel.org <linux-media-owner@vger.kernel.org> On
> > Behalf Of Mauro Carvalho Chehab
> > Sent: Friday, July 6, 2018 8:16 PM
> > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> <masami.hiramatsu@linaro.org>;
> > Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > demodulator driver
> >
> > Em Fri, 6 Jul 2018 15:04:08 +0900
> > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> >
> > > Here is the log of dvb-fe-tool on my environment.
> > >
> > > --------------------
> > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> > > Changing delivery system to: ISDBS
> > > ERROR FE_SET_VOLTAGE: Unknown error 524
> >
> > Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
> > LNBf?
>
> Ah, maybe it's not implemented yet in Helene driver.
That depends on how the hardware works. On some hardware, the
LNBf power supply and control is at the demod; on others, it is
supported by a separate chipset. See, for example, isl642.c for
an example of such external hardware.
I don't know much about ISDB-S, but, as far as what was
implemented on v4l-utils dvb-sat.c for Japan 110BS/CS LNBf,
the LNBf voltage is not used to switch the polarity.
So, the control here is simpler than on DVB-S/S2, as the only
control is either to send 18V to power on the LNBf/Dish, or
zero in order to save power.
>
>
> >
> > Anyway, I changed the error print message to be clearer, displaying
> > instead:
> >
> > ERROR FE_SET_VOLTAGE: driver doesn't support it!
> >
>
> It's nice for users. Thanks!
>
>
> > >
> > > # ./utils/dvb/.libs/dvb-fe-tool
> > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > CAN_FEC_AUTO
> > > CAN_GUARD_INTERVAL_AUTO
> > > CAN_HIERARCHY_AUTO
> > > CAN_INVERSION_AUTO
> > > CAN_QAM_AUTO
> > > CAN_TRANSMISSION_MODE_AUTO
> > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > Supported delivery systems:
> > > [ISDBS]
> > > ISDBT
> > > Frequency range for the current standard:
> > > From: 470 MHz
> > > To: 2.07 GHz
> > > Step: 25.0 kHz
> > > Symbol rate ranges for the current standard:
> > > From: 0Bauds
> > > To: 0Bauds
> >
> > That seems a driver issue. The ISDB-S ops.info should be
> > filling both symbol_rate_min and symbol_rate_max.
> >
> > I suspect that both should be filled with 28860000.
> >
> > The dvb_frontend.c core might hardcode it, but, IMHO,
> > it is better to keep those information inside the
> > tuner/frontend ops.info.
> >
>
> Indeed, thank you for reviewing. I fixed my driver. It seems works fine.
>
> ----
> # utils/dvb/.libs/dvb-fe-tool -a 0
> Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_FEC_AUTO
> CAN_GUARD_INTERVAL_AUTO
> CAN_HIERARCHY_AUTO
> CAN_INVERSION_AUTO
> CAN_QAM_AUTO
> CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.11, Current v5 delivery system: ISDBS
> Supported delivery systems:
> [ISDBS]
> ISDBT
> Frequency range for the current standard:
> From: 470 MHz
> To: 2.07 GHz
> Step: 25.0 kHz
> Symbol rate ranges for the current standard:
> From: 28.9 MBauds
> To: 28.9 MBauds
> SEC: set voltage to OFF
> ERROR FE_SET_VOLTAGE: Operation not permitted
> ----
That sounds ok.
>
>
> > > SEC: set voltage to OFF
> > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > >
> > >
> > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> > > Changing delivery system to: ISDBT
> > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > >
> > > # ./utils/dvb/.libs/dvb-fe-tool
> > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > CAN_FEC_AUTO
> > > CAN_GUARD_INTERVAL_AUTO
> > > CAN_HIERARCHY_AUTO
> > > CAN_INVERSION_AUTO
> > > CAN_QAM_AUTO
> > > CAN_TRANSMISSION_MODE_AUTO
> > > DVB API Version 5.11, Current v5 delivery system: ISDBT
> > > Supported delivery systems:
> > > ISDBS
> > > [ISDBT]
> > > Frequency range for the current standard:
> > > From: 470 MHz
> > > To: 2.07 GHz
> > > Step: 25.0 kHz
> >
> > The rest looks OK for me.
> >
> > > > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > > > >
> > > > > .name = "Sony HELENE Ter tuner",
> > > > > .frequency_min_hz = 1 * MHz,
> > > > > .frequency_max_hz = 1200 * MHz,
> > > > > .frequency_step_hz = 25 * kHz,
> > > > >
> > > > > .name = "Sony HELENE Sat tuner",
> > > > > .frequency_min_hz = 500 * MHz,
> > > > > .frequency_max_hz = 2500 * MHz,
> > > > > .frequency_step_hz = 1 * MHz,
> > > > >
> > > > > Is this better to add new info for both system?
> > > > >
> > > > > .name = "Sony HELENE Sat/Ter tuner",
> > > > > .frequency_min_hz = 1 * MHz,
> > > > > .frequency_max_hz = 2500 * MHz,
> > > > > .frequency_step_hz = 25 * kHz, // Is this correct...?
> > > >
> > > > That is indeed a very good question, and maybe a reason why we
> > > > may need other approaches.
> > > >
> > > > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > > > the frequency range should be ok. It would aget_frontend_algoctually be
> pretty
> > cool
> > > > to use a tuner with such wide range for SDR, if the hardware supports
> > > > raw I/Q collect :-D
> > > >
> > > > The frequency step is a different issue. If the tuner driver uses
> > > > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > > > this function is not defined), then the step will be used to adjust
> > > > the zigzag interactions. If it is too small, the tuning will lose
> > > > channels if the signal is not strong.
> > > >
> > >
> > > Thank you for describing. It's difficult problem...
> >
> > I double-checked the implementation. We don't need to worry about
> > zigzag, provided that the ISDB-S implementation at the core is correct.
> >
> > For satellite/cable standards, the zigzag logic takes the symbol
> > rate into account, and not the stepsize:
> >
> > case SYS_DVBS:
> > case SYS_DVBS2:
> > case SYS_ISDBS:
> > case SYS_TURBO:
> > case SYS_DVBC_ANNEX_A:
> > case SYS_DVBC_ANNEX_C:
> > fepriv->min_delay = HZ / 20;
> > fepriv->step_size = c->symbol_rate / 16000;
> > fepriv->max_drift = c->symbol_rate / 2000;
> > break;
> >
> > For terrestrial standards, it uses the stepsize:
> >
> > case SYS_DVBT:
> > case SYS_DVBT2:
> > case SYS_ISDBT:
> > case SYS_DTMB:
> > fepriv->min_delay = HZ / 20;
> > fepriv->step_size = dvb_frontend_get_stepsize(fe) * 2;
> > fepriv->max_drift = (dvb_frontend_get_stepsize(fe) * 2)
> +
> > 1;
> > break;
> >
> > So, having a value of 25 kHz there won't affect the zigzag algorithm
> > for ISDB-S, as it will be used only for ISDB-T.
> >
>
> Thank you for checking and describing. I checked it too.
>
> Default value is fine as you said, and we can use get_tune_settings()
> callback if we face the problem or need different settings for each
> delivery systems in the future.
>
> /* get frontend-specific tuning settings */
> memset(&fetunesettings, 0, sizeof(struct dvb_frontend_tune_settings));
> if (fe->ops.get_tune_settings && (fe->ops.get_tune_settings(fe,
> &fetunesettings) == 0)) {
> fepriv->min_delay = (fetunesettings.min_delay_ms * HZ) / 1000;
> fepriv->max_drift = fetunesettings.max_drift;
> fepriv->step_size = fetunesettings.step_size;
> } else {
> /* default values */
> ...
Sure.
>
>
> > > > In the specific case of helene, it doesn't have a get_frontend_algo,
> > > > so it will use the step frequency.
> > > >
> > > > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > > > here, if helene does sigzag in hardware or not.
> > > >
> > >
> > > As far as I know, Helene does not have automatic scan mechanism in
> > > hardware.
> >
> > Ok, so the driver is doing the right thing here.
> >
> > > > If it does in hardware, you could add a get_frontend_algo() routine
> > > > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > > > algorithm in the Kernel will stop, as it will rely at the hardware.
> > > >
> > > > Please notice that, if the hardware doesn't do zigzag itself, this
> > > > will make it lose channels. On the other hand, if the hardware does
> > > > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > > > Kernel won't try to do sigzag itself.
> > > >
> > >
> > > ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> > > BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> > > ISDB-T system and 25kHz is small for ISDB-S system.
> >
> > Yeah, but, after double-checking the logic, for ISDB-S, it will
> > use:
> >
> > c->symbol_rate = 28860000;
> > c->rolloff = ROLLOFF_35;
> > c->bandwidth_hz = c->symbol_rate / 100 * 135;
> >
> > That would actually set the ISDB-S channel separation to 38.961 MHz.
> >
> > By setting symbol_rate like that, the zigzag for ISDB-S will
> > be defined by:
> >
> > fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000 =
> .002435
> > - e. g. steps of ~25 kHz */
> > fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000 =
> .0194805
> > - e. g. max drift of ~195 kHz */
> >
> > Funny enough, it will be using about 25 kHz as step size for ISDB-S.
> >
> > I have no idea if the ISDB-S standard defines the zigzag logic,
> > but I would be expecting a higher value for it. So, perhaps
> > the ISDB-S zigzag could be optimized.
> >
> > Thanks,
> > Mauro
>
> Hmm, interesting. I don't know zigzag for ISDB-S too, sorry...
>
> Anyway, I don't worry about that. I said in above, we can use
> get_tune_settings() for fine tuning.
>
>
> Regards,
> --
> Katsuhiro Suzuki
>
>
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-09 13:59 ` Mauro Carvalho Chehab
@ 2018-07-10 2:50 ` Katsuhiro Suzuki
2018-07-17 6:07 ` Katsuhiro Suzuki
0 siblings, 1 reply; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-07-10 2:50 UTC (permalink / raw)
To: 'Mauro Carvalho Chehab',
Suzuki, Katsuhiro/鈴木 勝博
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Hello Mauro,
> -----Original Message-----
> From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Sent: Monday, July 9, 2018 11:00 PM
> To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> Cc: linux-media@vger.kernel.org; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> demodulator driver
>
> Em Mon, 9 Jul 2018 11:04:36 +0900
> "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
>
> > Hello Mauro,
> >
> > > -----Original Message-----
> > > From: linux-media-owner@vger.kernel.org <linux-media-owner@vger.kernel.org>
> On
> > > Behalf Of Mauro Carvalho Chehab
> > > Sent: Friday, July 6, 2018 8:16 PM
> > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > <masami.hiramatsu@linaro.org>;
> > > Jassi Brar <jaswinder.singh@linaro.org>;
> linux-arm-kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > demodulator driver
> > >
> > > Em Fri, 6 Jul 2018 15:04:08 +0900
> > > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> > >
> > > > Here is the log of dvb-fe-tool on my environment.
> > > >
> > > > --------------------
> > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> > > > Changing delivery system to: ISDBS
> > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > >
> > > Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
> > > LNBf?
> >
> > Ah, maybe it's not implemented yet in Helene driver.
>
> That depends on how the hardware works. On some hardware, the
> LNBf power supply and control is at the demod; on others, it is
> supported by a separate chipset. See, for example, isl642.c for
> an example of such external hardware.
>
> I don't know much about ISDB-S, but, as far as what was
> implemented on v4l-utils dvb-sat.c for Japan 110BS/CS LNBf,
> the LNBf voltage is not used to switch the polarity.
>
> So, the control here is simpler than on DVB-S/S2, as the only
> control is either to send 18V to power on the LNBf/Dish, or
> zero in order to save power.
>
Thank you, I misunderstood about LNB. I checked circuit of evaluation
board, the board has discrete LNB IC (ST micro LNBH29) for supplying
voltage to Helene. This IC is controlled by I2C.
The standard (ARIB STD-B21) says DC 15V power is needed to drive the
converter (BS freq -> BS-IF freq) of BS dish antenna. This power
can be supplied via antenna line.
It seems,
LNBH29 --(LNB_PWR)--> Helene --> BS antenna
I don't know enough about Helene, but it maybe supply 15V power to
converter of BS dish via antenna line if it receive 15V LNB_PWR...
I don't have idea about controlling this IC. Should I write some
driver for LNBH29, and pass the phandle to demodulator via device
tree??
> >
> >
> > >
> > > Anyway, I changed the error print message to be clearer, displaying
> > > instead:
> > >
> > > ERROR FE_SET_VOLTAGE: driver doesn't support it!
> > >
> >
> > It's nice for users. Thanks!
> >
> >
> > > >
> > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > CAN_FEC_AUTO
> > > > CAN_GUARD_INTERVAL_AUTO
> > > > CAN_HIERARCHY_AUTO
> > > > CAN_INVERSION_AUTO
> > > > CAN_QAM_AUTO
> > > > CAN_TRANSMISSION_MODE_AUTO
> > > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > > Supported delivery systems:
> > > > [ISDBS]
> > > > ISDBT
> > > > Frequency range for the current standard:
> > > > From: 470 MHz
> > > > To: 2.07 GHz
> > > > Step: 25.0 kHz
> > > > Symbol rate ranges for the current standard:
> > > > From: 0Bauds
> > > > To: 0Bauds
> > >
> > > That seems a driver issue. The ISDB-S ops.info should be
> > > filling both symbol_rate_min and symbol_rate_max.
> > >
> > > I suspect that both should be filled with 28860000.
> > >
> > > The dvb_frontend.c core might hardcode it, but, IMHO,
> > > it is better to keep those information inside the
> > > tuner/frontend ops.info.
> > >
> >
> > Indeed, thank you for reviewing. I fixed my driver. It seems works fine.
> >
> > ----
> > # utils/dvb/.libs/dvb-fe-tool -a 0
> > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > CAN_FEC_AUTO
> > CAN_GUARD_INTERVAL_AUTO
> > CAN_HIERARCHY_AUTO
> > CAN_INVERSION_AUTO
> > CAN_QAM_AUTO
> > CAN_TRANSMISSION_MODE_AUTO
> > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > Supported delivery systems:
> > [ISDBS]
> > ISDBT
> > Frequency range for the current standard:
> > From: 470 MHz
> > To: 2.07 GHz
> > Step: 25.0 kHz
> > Symbol rate ranges for the current standard:
> > From: 28.9 MBauds
> > To: 28.9 MBauds
> > SEC: set voltage to OFF
> > ERROR FE_SET_VOLTAGE: Operation not permitted
> > ----
>
> That sounds ok.
>
> >
> >
> > > > SEC: set voltage to OFF
> > > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > > >
> > > >
> > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> > > > Changing delivery system to: ISDBT
> > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > > >
> > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > CAN_FEC_AUTO
> > > > CAN_GUARD_INTERVAL_AUTO
> > > > CAN_HIERARCHY_AUTO
> > > > CAN_INVERSION_AUTO
> > > > CAN_QAM_AUTO
> > > > CAN_TRANSMISSION_MODE_AUTO
> > > > DVB API Version 5.11, Current v5 delivery system: ISDBT
> > > > Supported delivery systems:
> > > > ISDBS
> > > > [ISDBT]
> > > > Frequency range for the current standard:
> > > > From: 470 MHz
> > > > To: 2.07 GHz
> > > > Step: 25.0 kHz
> > >
> > > The rest looks OK for me.
> > >
> > > > > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > > > > >
> > > > > > .name = "Sony HELENE Ter tuner",
> > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > .frequency_max_hz = 1200 * MHz,
> > > > > > .frequency_step_hz = 25 * kHz,
> > > > > >
> > > > > > .name = "Sony HELENE Sat tuner",
> > > > > > .frequency_min_hz = 500 * MHz,
> > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > .frequency_step_hz = 1 * MHz,
> > > > > >
> > > > > > Is this better to add new info for both system?
> > > > > >
> > > > > > .name = "Sony HELENE Sat/Ter tuner",
> > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > .frequency_step_hz = 25 * kHz, // Is this correct...?
> > > > >
> > > > > That is indeed a very good question, and maybe a reason why we
> > > > > may need other approaches.
> > > > >
> > > > > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > > > > the frequency range should be ok. It would aget_frontend_algoctually be
> > pretty
> > > cool
> > > > > to use a tuner with such wide range for SDR, if the hardware supports
> > > > > raw I/Q collect :-D
> > > > >
> > > > > The frequency step is a different issue. If the tuner driver uses
> > > > > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > > > > this function is not defined), then the step will be used to adjust
> > > > > the zigzag interactions. If it is too small, the tuning will lose
> > > > > channels if the signal is not strong.
> > > > >
> > > >
> > > > Thank you for describing. It's difficult problem...
> > >
> > > I double-checked the implementation. We don't need to worry about
> > > zigzag, provided that the ISDB-S implementation at the core is correct.
> > >
> > > For satellite/cable standards, the zigzag logic takes the symbol
> > > rate into account, and not the stepsize:
> > >
> > > case SYS_DVBS:
> > > case SYS_DVBS2:
> > > case SYS_ISDBS:
> > > case SYS_TURBO:
> > > case SYS_DVBC_ANNEX_A:
> > > case SYS_DVBC_ANNEX_C:
> > > fepriv->min_delay = HZ / 20;
> > > fepriv->step_size = c->symbol_rate / 16000;
> > > fepriv->max_drift = c->symbol_rate / 2000;
> > > break;
> > >
> > > For terrestrial standards, it uses the stepsize:
> > >
> > > case SYS_DVBT:
> > > case SYS_DVBT2:
> > > case SYS_ISDBT:
> > > case SYS_DTMB:
> > > fepriv->min_delay = HZ / 20;
> > > fepriv->step_size = dvb_frontend_get_stepsize(fe) *
> 2;
> > > fepriv->max_drift = (dvb_frontend_get_stepsize(fe) *
> 2)
> > +
> > > 1;
> > > break;
> > >
> > > So, having a value of 25 kHz there won't affect the zigzag algorithm
> > > for ISDB-S, as it will be used only for ISDB-T.
> > >
> >
> > Thank you for checking and describing. I checked it too.
> >
> > Default value is fine as you said, and we can use get_tune_settings()
> > callback if we face the problem or need different settings for each
> > delivery systems in the future.
> >
> > /* get frontend-specific tuning settings */
> > memset(&fetunesettings, 0, sizeof(struct dvb_frontend_tune_settings));
> > if (fe->ops.get_tune_settings && (fe->ops.get_tune_settings(fe,
> > &fetunesettings) == 0)) {
> > fepriv->min_delay = (fetunesettings.min_delay_ms * HZ) / 1000;
> > fepriv->max_drift = fetunesettings.max_drift;
> > fepriv->step_size = fetunesettings.step_size;
> > } else {
> > /* default values */
> > ...
>
> Sure.
>
> >
> >
> > > > > In the specific case of helene, it doesn't have a get_frontend_algo,
> > > > > so it will use the step frequency.
> > > > >
> > > > > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > > > > here, if helene does sigzag in hardware or not.
> > > > >
> > > >
> > > > As far as I know, Helene does not have automatic scan mechanism in
> > > > hardware.
> > >
> > > Ok, so the driver is doing the right thing here.
> > >
> > > > > If it does in hardware, you could add a get_frontend_algo() routine
> > > > > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > > > > algorithm in the Kernel will stop, as it will rely at the hardware.
> > > > >
> > > > > Please notice that, if the hardware doesn't do zigzag itself, this
> > > > > will make it lose channels. On the other hand, if the hardware does
> > > > > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > > > > Kernel won't try to do sigzag itself.
> > > > >
> > > >
> > > > ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> > > > BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> > > > ISDB-T system and 25kHz is small for ISDB-S system.
> > >
> > > Yeah, but, after double-checking the logic, for ISDB-S, it will
> > > use:
> > >
> > > c->symbol_rate = 28860000;
> > > c->rolloff = ROLLOFF_35;
> > > c->bandwidth_hz = c->symbol_rate / 100 * 135;
> > >
> > > That would actually set the ISDB-S channel separation to 38.961 MHz.
> > >
> > > By setting symbol_rate like that, the zigzag for ISDB-S will
> > > be defined by:
> > >
> > > fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000 =
> > .002435
> > > - e. g. steps of ~25 kHz */
> > > fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000 =
> > .0194805
> > > - e. g. max drift of ~195 kHz */
> > >
> > > Funny enough, it will be using about 25 kHz as step size for ISDB-S.
> > >
> > > I have no idea if the ISDB-S standard defines the zigzag logic,
> > > but I would be expecting a higher value for it. So, perhaps
> > > the ISDB-S zigzag could be optimized.
> > >
> > > Thanks,
> > > Mauro
> >
> > Hmm, interesting. I don't know zigzag for ISDB-S too, sorry...
> >
> > Anyway, I don't worry about that. I said in above, we can use
> > get_tune_settings() for fine tuning.
> >
> >
> > Regards,
> > --
> > Katsuhiro Suzuki
> >
> >
> >
>
>
>
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-10 2:50 ` Katsuhiro Suzuki
@ 2018-07-17 6:07 ` Katsuhiro Suzuki
2018-07-17 10:58 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-07-17 6:07 UTC (permalink / raw)
To: 'Mauro Carvalho Chehab',
Suzuki, Katsuhiro/鈴木 勝博
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Hello Mauro,
I want to send next version (v4) of this patch (just fix wrong max/min range of
frequency, fix symbol rate). But it depends your patches for DVB cores.
Which way is better?
- Send next version now
- Send next version after your DVB cores patches applied
I want to try to solve LNB problem after current codes applied. I think LNB IC
will be defined as regulator device. Please tell me if you have comments about
it.
Regards,
--
Katsuhiro Suzuki
> -----Original Message-----
> From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> Sent: Tuesday, July 10, 2018 11:51 AM
> To: 'Mauro Carvalho Chehab' <mchehab+samsung@kernel.org>; Suzuki, Katsuhiro/鈴木
> 勝博 <suzuki.katsuhiro@socionext.com>
> Cc: linux-media@vger.kernel.org; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> demodulator driver
>
> Hello Mauro,
>
> > -----Original Message-----
> > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Sent: Monday, July 9, 2018 11:00 PM
> > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> <masami.hiramatsu@linaro.org>;
> > Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > demodulator driver
> >
> > Em Mon, 9 Jul 2018 11:04:36 +0900
> > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> >
> > > Hello Mauro,
> > >
> > > > -----Original Message-----
> > > > From: linux-media-owner@vger.kernel.org <linux-media-owner@vger.kernel.org>
> > On
> > > > Behalf Of Mauro Carvalho Chehab
> > > > Sent: Friday, July 6, 2018 8:16 PM
> > > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > > <masami.hiramatsu@linaro.org>;
> > > > Jassi Brar <jaswinder.singh@linaro.org>;
> > linux-arm-kernel@lists.infradead.org;
> > > > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > > demodulator driver
> > > >
> > > > Em Fri, 6 Jul 2018 15:04:08 +0900
> > > > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> > > >
> > > > > Here is the log of dvb-fe-tool on my environment.
> > > > >
> > > > > --------------------
> > > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> > > > > Changing delivery system to: ISDBS
> > > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > > >
> > > > Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
> > > > LNBf?
> > >
> > > Ah, maybe it's not implemented yet in Helene driver.
> >
> > That depends on how the hardware works. On some hardware, the
> > LNBf power supply and control is at the demod; on others, it is
> > supported by a separate chipset. See, for example, isl642.c for
> > an example of such external hardware.
> >
> > I don't know much about ISDB-S, but, as far as what was
> > implemented on v4l-utils dvb-sat.c for Japan 110BS/CS LNBf,
> > the LNBf voltage is not used to switch the polarity.
> >
> > So, the control here is simpler than on DVB-S/S2, as the only
> > control is either to send 18V to power on the LNBf/Dish, or
> > zero in order to save power.
> >
>
> Thank you, I misunderstood about LNB. I checked circuit of evaluation
> board, the board has discrete LNB IC (ST micro LNBH29) for supplying
> voltage to Helene. This IC is controlled by I2C.
>
> The standard (ARIB STD-B21) says DC 15V power is needed to drive the
> converter (BS freq -> BS-IF freq) of BS dish antenna. This power
> can be supplied via antenna line.
>
> It seems,
> LNBH29 --(LNB_PWR)--> Helene --> BS antenna
>
> I don't know enough about Helene, but it maybe supply 15V power to
> converter of BS dish via antenna line if it receive 15V LNB_PWR...
>
>
> I don't have idea about controlling this IC. Should I write some
> driver for LNBH29, and pass the phandle to demodulator via device
> tree??
>
>
> > >
> > >
> > > >
> > > > Anyway, I changed the error print message to be clearer, displaying
> > > > instead:
> > > >
> > > > ERROR FE_SET_VOLTAGE: driver doesn't support it!
> > > >
> > >
> > > It's nice for users. Thanks!
> > >
> > >
> > > > >
> > > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > > CAN_FEC_AUTO
> > > > > CAN_GUARD_INTERVAL_AUTO
> > > > > CAN_HIERARCHY_AUTO
> > > > > CAN_INVERSION_AUTO
> > > > > CAN_QAM_AUTO
> > > > > CAN_TRANSMISSION_MODE_AUTO
> > > > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > > > Supported delivery systems:
> > > > > [ISDBS]
> > > > > ISDBT
> > > > > Frequency range for the current standard:
> > > > > From: 470 MHz
> > > > > To: 2.07 GHz
> > > > > Step: 25.0 kHz
> > > > > Symbol rate ranges for the current standard:
> > > > > From: 0Bauds
> > > > > To: 0Bauds
> > > >
> > > > That seems a driver issue. The ISDB-S ops.info should be
> > > > filling both symbol_rate_min and symbol_rate_max.
> > > >
> > > > I suspect that both should be filled with 28860000.
> > > >
> > > > The dvb_frontend.c core might hardcode it, but, IMHO,
> > > > it is better to keep those information inside the
> > > > tuner/frontend ops.info.
> > > >
> > >
> > > Indeed, thank you for reviewing. I fixed my driver. It seems works fine.
> > >
> > > ----
> > > # utils/dvb/.libs/dvb-fe-tool -a 0
> > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > CAN_FEC_AUTO
> > > CAN_GUARD_INTERVAL_AUTO
> > > CAN_HIERARCHY_AUTO
> > > CAN_INVERSION_AUTO
> > > CAN_QAM_AUTO
> > > CAN_TRANSMISSION_MODE_AUTO
> > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > Supported delivery systems:
> > > [ISDBS]
> > > ISDBT
> > > Frequency range for the current standard:
> > > From: 470 MHz
> > > To: 2.07 GHz
> > > Step: 25.0 kHz
> > > Symbol rate ranges for the current standard:
> > > From: 28.9 MBauds
> > > To: 28.9 MBauds
> > > SEC: set voltage to OFF
> > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > > ----
> >
> > That sounds ok.
> >
> > >
> > >
> > > > > SEC: set voltage to OFF
> > > > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > > > >
> > > > >
> > > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> > > > > Changing delivery system to: ISDBT
> > > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > > > >
> > > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > > CAN_FEC_AUTO
> > > > > CAN_GUARD_INTERVAL_AUTO
> > > > > CAN_HIERARCHY_AUTO
> > > > > CAN_INVERSION_AUTO
> > > > > CAN_QAM_AUTO
> > > > > CAN_TRANSMISSION_MODE_AUTO
> > > > > DVB API Version 5.11, Current v5 delivery system: ISDBT
> > > > > Supported delivery systems:
> > > > > ISDBS
> > > > > [ISDBT]
> > > > > Frequency range for the current standard:
> > > > > From: 470 MHz
> > > > > To: 2.07 GHz
> > > > > Step: 25.0 kHz
> > > >
> > > > The rest looks OK for me.
> > > >
> > > > > > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > > > > > >
> > > > > > > .name = "Sony HELENE Ter tuner",
> > > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > > .frequency_max_hz = 1200 * MHz,
> > > > > > > .frequency_step_hz = 25 * kHz,
> > > > > > >
> > > > > > > .name = "Sony HELENE Sat tuner",
> > > > > > > .frequency_min_hz = 500 * MHz,
> > > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > > .frequency_step_hz = 1 * MHz,
> > > > > > >
> > > > > > > Is this better to add new info for both system?
> > > > > > >
> > > > > > > .name = "Sony HELENE Sat/Ter tuner",
> > > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > > .frequency_step_hz = 25 * kHz, // Is this correct...?
> > > > > >
> > > > > > That is indeed a very good question, and maybe a reason why we
> > > > > > may need other approaches.
> > > > > >
> > > > > > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > > > > > the frequency range should be ok. It would aget_frontend_algoctually be
> > > pretty
> > > > cool
> > > > > > to use a tuner with such wide range for SDR, if the hardware supports
> > > > > > raw I/Q collect :-D
> > > > > >
> > > > > > The frequency step is a different issue. If the tuner driver uses
> > > > > > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > > > > > this function is not defined), then the step will be used to adjust
> > > > > > the zigzag interactions. If it is too small, the tuning will lose
> > > > > > channels if the signal is not strong.
> > > > > >
> > > > >
> > > > > Thank you for describing. It's difficult problem...
> > > >
> > > > I double-checked the implementation. We don't need to worry about
> > > > zigzag, provided that the ISDB-S implementation at the core is correct.
> > > >
> > > > For satellite/cable standards, the zigzag logic takes the symbol
> > > > rate into account, and not the stepsize:
> > > >
> > > > case SYS_DVBS:
> > > > case SYS_DVBS2:
> > > > case SYS_ISDBS:
> > > > case SYS_TURBO:
> > > > case SYS_DVBC_ANNEX_A:
> > > > case SYS_DVBC_ANNEX_C:
> > > > fepriv->min_delay = HZ / 20;
> > > > fepriv->step_size = c->symbol_rate / 16000;
> > > > fepriv->max_drift = c->symbol_rate / 2000;
> > > > break;
> > > >
> > > > For terrestrial standards, it uses the stepsize:
> > > >
> > > > case SYS_DVBT:
> > > > case SYS_DVBT2:
> > > > case SYS_ISDBT:
> > > > case SYS_DTMB:
> > > > fepriv->min_delay = HZ / 20;
> > > > fepriv->step_size = dvb_frontend_get_stepsize(fe) *
> > 2;
> > > > fepriv->max_drift = (dvb_frontend_get_stepsize(fe)
> *
> > 2)
> > > +
> > > > 1;
> > > > break;
> > > >
> > > > So, having a value of 25 kHz there won't affect the zigzag algorithm
> > > > for ISDB-S, as it will be used only for ISDB-T.
> > > >
> > >
> > > Thank you for checking and describing. I checked it too.
> > >
> > > Default value is fine as you said, and we can use get_tune_settings()
> > > callback if we face the problem or need different settings for each
> > > delivery systems in the future.
> > >
> > > /* get frontend-specific tuning settings */
> > > memset(&fetunesettings, 0, sizeof(struct
> dvb_frontend_tune_settings));
> > > if (fe->ops.get_tune_settings && (fe->ops.get_tune_settings(fe,
> > > &fetunesettings) == 0)) {
> > > fepriv->min_delay = (fetunesettings.min_delay_ms * HZ) / 1000;
> > > fepriv->max_drift = fetunesettings.max_drift;
> > > fepriv->step_size = fetunesettings.step_size;
> > > } else {
> > > /* default values */
> > > ...
> >
> > Sure.
> >
> > >
> > >
> > > > > > In the specific case of helene, it doesn't have a get_frontend_algo,
> > > > > > so it will use the step frequency.
> > > > > >
> > > > > > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > > > > > here, if helene does sigzag in hardware or not.
> > > > > >
> > > > >
> > > > > As far as I know, Helene does not have automatic scan mechanism in
> > > > > hardware.
> > > >
> > > > Ok, so the driver is doing the right thing here.
> > > >
> > > > > > If it does in hardware, you could add a get_frontend_algo() routine
> > > > > > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > > > > > algorithm in the Kernel will stop, as it will rely at the hardware.
> > > > > >
> > > > > > Please notice that, if the hardware doesn't do zigzag itself, this
> > > > > > will make it lose channels. On the other hand, if the hardware does
> > > > > > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > > > > > Kernel won't try to do sigzag itself.
> > > > > >
> > > > >
> > > > > ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> > > > > BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> > > > > ISDB-T system and 25kHz is small for ISDB-S system.
> > > >
> > > > Yeah, but, after double-checking the logic, for ISDB-S, it will
> > > > use:
> > > >
> > > > c->symbol_rate = 28860000;
> > > > c->rolloff = ROLLOFF_35;
> > > > c->bandwidth_hz = c->symbol_rate / 100 * 135;
> > > >
> > > > That would actually set the ISDB-S channel separation to 38.961 MHz.
> > > >
> > > > By setting symbol_rate like that, the zigzag for ISDB-S will
> > > > be defined by:
> > > >
> > > > fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000 =
> > > .002435
> > > > - e. g. steps of ~25 kHz */
> > > > fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000 =
> > > .0194805
> > > > - e. g. max drift of ~195 kHz */
> > > >
> > > > Funny enough, it will be using about 25 kHz as step size for ISDB-S.
> > > >
> > > > I have no idea if the ISDB-S standard defines the zigzag logic,
> > > > but I would be expecting a higher value for it. So, perhaps
> > > > the ISDB-S zigzag could be optimized.
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > Hmm, interesting. I don't know zigzag for ISDB-S too, sorry...
> > >
> > > Anyway, I don't worry about that. I said in above, we can use
> > > get_tune_settings() for fine tuning.
> > >
> > >
> > > Regards,
> > > --
> > > Katsuhiro Suzuki
> > >
> > >
> > >
> >
> >
> >
> > Thanks,
> > Mauro
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-17 6:07 ` Katsuhiro Suzuki
@ 2018-07-17 10:58 ` Mauro Carvalho Chehab
2018-07-18 0:39 ` Katsuhiro Suzuki
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-17 10:58 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Em Tue, 17 Jul 2018 15:07:32 +0900
"Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> Hello Mauro,
>
> I want to send next version (v4) of this patch (just fix wrong max/min range of
> frequency, fix symbol rate). But it depends your patches for DVB cores.
>
> Which way is better?
>
> - Send next version now
> - Send next version after your DVB cores patches applied
>
> I want to try to solve LNB problem after current codes applied. I think LNB IC
> will be defined as regulator device. Please tell me if you have comments about
> it.
I'm out of the town this week, but you can send it. No need to wait for
my patches. Just add a notice that the patch depends on them. I'll
handle after returning back from my trip.
>
>
> Regards,
> --
> Katsuhiro Suzuki
>
>
> > -----Original Message-----
> > From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> > Sent: Tuesday, July 10, 2018 11:51 AM
> > To: 'Mauro Carvalho Chehab' <mchehab+samsung@kernel.org>; Suzuki, Katsuhiro/鈴木
> > 勝博 <suzuki.katsuhiro@socionext.com>
> > Cc: linux-media@vger.kernel.org; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> > Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > demodulator driver
> >
> > Hello Mauro,
> >
> > > -----Original Message-----
> > > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > Sent: Monday, July 9, 2018 11:00 PM
> > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > <masami.hiramatsu@linaro.org>;
> > > Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > demodulator driver
> > >
> > > Em Mon, 9 Jul 2018 11:04:36 +0900
> > > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> > >
> > > > Hello Mauro,
> > > >
> > > > > -----Original Message-----
> > > > > From: linux-media-owner@vger.kernel.org <linux-media-owner@vger.kernel.org>
> > > On
> > > > > Behalf Of Mauro Carvalho Chehab
> > > > > Sent: Friday, July 6, 2018 8:16 PM
> > > > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > > > <masami.hiramatsu@linaro.org>;
> > > > > Jassi Brar <jaswinder.singh@linaro.org>;
> > > linux-arm-kernel@lists.infradead.org;
> > > > > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > > > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > > > demodulator driver
> > > > >
> > > > > Em Fri, 6 Jul 2018 15:04:08 +0900
> > > > > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> > > > >
> > > > > > Here is the log of dvb-fe-tool on my environment.
> > > > > >
> > > > > > --------------------
> > > > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> > > > > > Changing delivery system to: ISDBS
> > > > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > > > >
> > > > > Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
> > > > > LNBf?
> > > >
> > > > Ah, maybe it's not implemented yet in Helene driver.
> > >
> > > That depends on how the hardware works. On some hardware, the
> > > LNBf power supply and control is at the demod; on others, it is
> > > supported by a separate chipset. See, for example, isl642.c for
> > > an example of such external hardware.
> > >
> > > I don't know much about ISDB-S, but, as far as what was
> > > implemented on v4l-utils dvb-sat.c for Japan 110BS/CS LNBf,
> > > the LNBf voltage is not used to switch the polarity.
> > >
> > > So, the control here is simpler than on DVB-S/S2, as the only
> > > control is either to send 18V to power on the LNBf/Dish, or
> > > zero in order to save power.
> > >
> >
> > Thank you, I misunderstood about LNB. I checked circuit of evaluation
> > board, the board has discrete LNB IC (ST micro LNBH29) for supplying
> > voltage to Helene. This IC is controlled by I2C.
> >
> > The standard (ARIB STD-B21) says DC 15V power is needed to drive the
> > converter (BS freq -> BS-IF freq) of BS dish antenna. This power
> > can be supplied via antenna line.
> >
> > It seems,
> > LNBH29 --(LNB_PWR)--> Helene --> BS antenna
> >
> > I don't know enough about Helene, but it maybe supply 15V power to
> > converter of BS dish via antenna line if it receive 15V LNB_PWR...
> >
> >
> > I don't have idea about controlling this IC. Should I write some
> > driver for LNBH29, and pass the phandle to demodulator via device
> > tree??
> >
> >
> > > >
> > > >
> > > > >
> > > > > Anyway, I changed the error print message to be clearer, displaying
> > > > > instead:
> > > > >
> > > > > ERROR FE_SET_VOLTAGE: driver doesn't support it!
> > > > >
> > > >
> > > > It's nice for users. Thanks!
> > > >
> > > >
> > > > > >
> > > > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > > > CAN_FEC_AUTO
> > > > > > CAN_GUARD_INTERVAL_AUTO
> > > > > > CAN_HIERARCHY_AUTO
> > > > > > CAN_INVERSION_AUTO
> > > > > > CAN_QAM_AUTO
> > > > > > CAN_TRANSMISSION_MODE_AUTO
> > > > > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > > > > Supported delivery systems:
> > > > > > [ISDBS]
> > > > > > ISDBT
> > > > > > Frequency range for the current standard:
> > > > > > From: 470 MHz
> > > > > > To: 2.07 GHz
> > > > > > Step: 25.0 kHz
> > > > > > Symbol rate ranges for the current standard:
> > > > > > From: 0Bauds
> > > > > > To: 0Bauds
> > > > >
> > > > > That seems a driver issue. The ISDB-S ops.info should be
> > > > > filling both symbol_rate_min and symbol_rate_max.
> > > > >
> > > > > I suspect that both should be filled with 28860000.
> > > > >
> > > > > The dvb_frontend.c core might hardcode it, but, IMHO,
> > > > > it is better to keep those information inside the
> > > > > tuner/frontend ops.info.
> > > > >
> > > >
> > > > Indeed, thank you for reviewing. I fixed my driver. It seems works fine.
> > > >
> > > > ----
> > > > # utils/dvb/.libs/dvb-fe-tool -a 0
> > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > CAN_FEC_AUTO
> > > > CAN_GUARD_INTERVAL_AUTO
> > > > CAN_HIERARCHY_AUTO
> > > > CAN_INVERSION_AUTO
> > > > CAN_QAM_AUTO
> > > > CAN_TRANSMISSION_MODE_AUTO
> > > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > > Supported delivery systems:
> > > > [ISDBS]
> > > > ISDBT
> > > > Frequency range for the current standard:
> > > > From: 470 MHz
> > > > To: 2.07 GHz
> > > > Step: 25.0 kHz
> > > > Symbol rate ranges for the current standard:
> > > > From: 28.9 MBauds
> > > > To: 28.9 MBauds
> > > > SEC: set voltage to OFF
> > > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > > > ----
> > >
> > > That sounds ok.
> > >
> > > >
> > > >
> > > > > > SEC: set voltage to OFF
> > > > > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > > > > >
> > > > > >
> > > > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> > > > > > Changing delivery system to: ISDBT
> > > > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > > > > >
> > > > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > > > CAN_FEC_AUTO
> > > > > > CAN_GUARD_INTERVAL_AUTO
> > > > > > CAN_HIERARCHY_AUTO
> > > > > > CAN_INVERSION_AUTO
> > > > > > CAN_QAM_AUTO
> > > > > > CAN_TRANSMISSION_MODE_AUTO
> > > > > > DVB API Version 5.11, Current v5 delivery system: ISDBT
> > > > > > Supported delivery systems:
> > > > > > ISDBS
> > > > > > [ISDBT]
> > > > > > Frequency range for the current standard:
> > > > > > From: 470 MHz
> > > > > > To: 2.07 GHz
> > > > > > Step: 25.0 kHz
> > > > >
> > > > > The rest looks OK for me.
> > > > >
> > > > > > > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > > > > > > >
> > > > > > > > .name = "Sony HELENE Ter tuner",
> > > > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > > > .frequency_max_hz = 1200 * MHz,
> > > > > > > > .frequency_step_hz = 25 * kHz,
> > > > > > > >
> > > > > > > > .name = "Sony HELENE Sat tuner",
> > > > > > > > .frequency_min_hz = 500 * MHz,
> > > > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > > > .frequency_step_hz = 1 * MHz,
> > > > > > > >
> > > > > > > > Is this better to add new info for both system?
> > > > > > > >
> > > > > > > > .name = "Sony HELENE Sat/Ter tuner",
> > > > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > > > .frequency_step_hz = 25 * kHz, // Is this correct...?
> > > > > > >
> > > > > > > That is indeed a very good question, and maybe a reason why we
> > > > > > > may need other approaches.
> > > > > > >
> > > > > > > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > > > > > > the frequency range should be ok. It would aget_frontend_algoctually be
> > > > pretty
> > > > > cool
> > > > > > > to use a tuner with such wide range for SDR, if the hardware supports
> > > > > > > raw I/Q collect :-D
> > > > > > >
> > > > > > > The frequency step is a different issue. If the tuner driver uses
> > > > > > > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > > > > > > this function is not defined), then the step will be used to adjust
> > > > > > > the zigzag interactions. If it is too small, the tuning will lose
> > > > > > > channels if the signal is not strong.
> > > > > > >
> > > > > >
> > > > > > Thank you for describing. It's difficult problem...
> > > > >
> > > > > I double-checked the implementation. We don't need to worry about
> > > > > zigzag, provided that the ISDB-S implementation at the core is correct.
> > > > >
> > > > > For satellite/cable standards, the zigzag logic takes the symbol
> > > > > rate into account, and not the stepsize:
> > > > >
> > > > > case SYS_DVBS:
> > > > > case SYS_DVBS2:
> > > > > case SYS_ISDBS:
> > > > > case SYS_TURBO:
> > > > > case SYS_DVBC_ANNEX_A:
> > > > > case SYS_DVBC_ANNEX_C:
> > > > > fepriv->min_delay = HZ / 20;
> > > > > fepriv->step_size = c->symbol_rate / 16000;
> > > > > fepriv->max_drift = c->symbol_rate / 2000;
> > > > > break;
> > > > >
> > > > > For terrestrial standards, it uses the stepsize:
> > > > >
> > > > > case SYS_DVBT:
> > > > > case SYS_DVBT2:
> > > > > case SYS_ISDBT:
> > > > > case SYS_DTMB:
> > > > > fepriv->min_delay = HZ / 20;
> > > > > fepriv->step_size = dvb_frontend_get_stepsize(fe) *
> > > 2;
> > > > > fepriv->max_drift = (dvb_frontend_get_stepsize(fe)
> > *
> > > 2)
> > > > +
> > > > > 1;
> > > > > break;
> > > > >
> > > > > So, having a value of 25 kHz there won't affect the zigzag algorithm
> > > > > for ISDB-S, as it will be used only for ISDB-T.
> > > > >
> > > >
> > > > Thank you for checking and describing. I checked it too.
> > > >
> > > > Default value is fine as you said, and we can use get_tune_settings()
> > > > callback if we face the problem or need different settings for each
> > > > delivery systems in the future.
> > > >
> > > > /* get frontend-specific tuning settings */
> > > > memset(&fetunesettings, 0, sizeof(struct
> > dvb_frontend_tune_settings));
> > > > if (fe->ops.get_tune_settings && (fe->ops.get_tune_settings(fe,
> > > > &fetunesettings) == 0)) {
> > > > fepriv->min_delay = (fetunesettings.min_delay_ms * HZ) / 1000;
> > > > fepriv->max_drift = fetunesettings.max_drift;
> > > > fepriv->step_size = fetunesettings.step_size;
> > > > } else {
> > > > /* default values */
> > > > ...
> > >
> > > Sure.
> > >
> > > >
> > > >
> > > > > > > In the specific case of helene, it doesn't have a get_frontend_algo,
> > > > > > > so it will use the step frequency.
> > > > > > >
> > > > > > > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > > > > > > here, if helene does sigzag in hardware or not.
> > > > > > >
> > > > > >
> > > > > > As far as I know, Helene does not have automatic scan mechanism in
> > > > > > hardware.
> > > > >
> > > > > Ok, so the driver is doing the right thing here.
> > > > >
> > > > > > > If it does in hardware, you could add a get_frontend_algo() routine
> > > > > > > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > > > > > > algorithm in the Kernel will stop, as it will rely at the hardware.
> > > > > > >
> > > > > > > Please notice that, if the hardware doesn't do zigzag itself, this
> > > > > > > will make it lose channels. On the other hand, if the hardware does
> > > > > > > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > > > > > > Kernel won't try to do sigzag itself.
> > > > > > >
> > > > > >
> > > > > > ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> > > > > > BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> > > > > > ISDB-T system and 25kHz is small for ISDB-S system.
> > > > >
> > > > > Yeah, but, after double-checking the logic, for ISDB-S, it will
> > > > > use:
> > > > >
> > > > > c->symbol_rate = 28860000;
> > > > > c->rolloff = ROLLOFF_35;
> > > > > c->bandwidth_hz = c->symbol_rate / 100 * 135;
> > > > >
> > > > > That would actually set the ISDB-S channel separation to 38.961 MHz.
> > > > >
> > > > > By setting symbol_rate like that, the zigzag for ISDB-S will
> > > > > be defined by:
> > > > >
> > > > > fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000 =
> > > > .002435
> > > > > - e. g. steps of ~25 kHz */
> > > > > fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000 =
> > > > .0194805
> > > > > - e. g. max drift of ~195 kHz */
> > > > >
> > > > > Funny enough, it will be using about 25 kHz as step size for ISDB-S.
> > > > >
> > > > > I have no idea if the ISDB-S standard defines the zigzag logic,
> > > > > but I would be expecting a higher value for it. So, perhaps
> > > > > the ISDB-S zigzag could be optimized.
> > > > >
> > > > > Thanks,
> > > > > Mauro
> > > >
> > > > Hmm, interesting. I don't know zigzag for ISDB-S too, sorry...
> > > >
> > > > Anyway, I don't worry about that. I said in above, we can use
> > > > get_tune_settings() for fine tuning.
> > > >
> > > >
> > > > Regards,
> > > > --
> > > > Katsuhiro Suzuki
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Thanks,
> > > Mauro
> >
>
>
>
Cheers,
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver
2018-07-17 10:58 ` Mauro Carvalho Chehab
@ 2018-07-18 0:39 ` Katsuhiro Suzuki
0 siblings, 0 replies; 14+ messages in thread
From: Katsuhiro Suzuki @ 2018-07-18 0:39 UTC (permalink / raw)
To: 'Mauro Carvalho Chehab',
Suzuki, Katsuhiro/鈴木 勝博
Cc: linux-media, Masami Hiramatsu, Jassi Brar, linux-arm-kernel,
linux-kernel, Abylay Ospan
Hello Mauro,
> -----Original Message-----
> From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Sent: Tuesday, July 17, 2018 7:59 PM
> To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> Cc: linux-media@vger.kernel.org; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> demodulator driver
>
> Em Tue, 17 Jul 2018 15:07:32 +0900
> "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
>
> > Hello Mauro,
> >
> > I want to send next version (v4) of this patch (just fix wrong max/min range of
> > frequency, fix symbol rate). But it depends your patches for DVB cores.
> >
> > Which way is better?
> >
> > - Send next version now
> > - Send next version after your DVB cores patches applied
> >
> > I want to try to solve LNB problem after current codes applied. I think LNB IC
> > will be defined as regulator device. Please tell me if you have comments about
> > it.
>
> I'm out of the town this week, but you can send it. No need to wait for
> my patches. Just add a notice that the patch depends on them. I'll
> handle after returning back from my trip.
>
Thank you, I see. Have a nice trip!
Regards,
--
Katsuhiro Suzuki
> >
> >
> > Regards,
> > --
> > Katsuhiro Suzuki
> >
> >
> > > -----Original Message-----
> > > From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> > > Sent: Tuesday, July 10, 2018 11:51 AM
> > > To: 'Mauro Carvalho Chehab' <mchehab+samsung@kernel.org>; Suzuki, Katsuhiro/
> 鈴木
> > > 勝博 <suzuki.katsuhiro@socionext.com>
> > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> <masami.hiramatsu@linaro.org>;
> > > Jassi Brar <jaswinder.singh@linaro.org>;
> linux-arm-kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > demodulator driver
> > >
> > > Hello Mauro,
> > >
> > > > -----Original Message-----
> > > > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > > Sent: Monday, July 9, 2018 11:00 PM
> > > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > > <masami.hiramatsu@linaro.org>;
> > > > Jassi Brar <jaswinder.singh@linaro.org>;
> linux-arm-kernel@lists.infradead.org;
> > > > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > > demodulator driver
> > > >
> > > > Em Mon, 9 Jul 2018 11:04:36 +0900
> > > > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> > > >
> > > > > Hello Mauro,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: linux-media-owner@vger.kernel.org
> <linux-media-owner@vger.kernel.org>
> > > > On
> > > > > > Behalf Of Mauro Carvalho Chehab
> > > > > > Sent: Friday, July 6, 2018 8:16 PM
> > > > > > To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro@socionext.com>
> > > > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu
> > > > > <masami.hiramatsu@linaro.org>;
> > > > > > Jassi Brar <jaswinder.singh@linaro.org>;
> > > > linux-arm-kernel@lists.infradead.org;
> > > > > > linux-kernel@vger.kernel.org; Abylay Ospan <aospan@netup.ru>
> > > > > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T
> > > > > > demodulator driver
> > > > > >
> > > > > > Em Fri, 6 Jul 2018 15:04:08 +0900
> > > > > > "Katsuhiro Suzuki" <suzuki.katsuhiro@socionext.com> escreveu:
> > > > > >
> > > > > > > Here is the log of dvb-fe-tool on my environment.
> > > > > > >
> > > > > > > --------------------
> > > > > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> > > > > > > Changing delivery system to: ISDBS
> > > > > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > > > > >
> > > > > > Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
> > > > > > LNBf?
> > > > >
> > > > > Ah, maybe it's not implemented yet in Helene driver.
> > > >
> > > > That depends on how the hardware works. On some hardware, the
> > > > LNBf power supply and control is at the demod; on others, it is
> > > > supported by a separate chipset. See, for example, isl642.c for
> > > > an example of such external hardware.
> > > >
> > > > I don't know much about ISDB-S, but, as far as what was
> > > > implemented on v4l-utils dvb-sat.c for Japan 110BS/CS LNBf,
> > > > the LNBf voltage is not used to switch the polarity.
> > > >
> > > > So, the control here is simpler than on DVB-S/S2, as the only
> > > > control is either to send 18V to power on the LNBf/Dish, or
> > > > zero in order to save power.
> > > >
> > >
> > > Thank you, I misunderstood about LNB. I checked circuit of evaluation
> > > board, the board has discrete LNB IC (ST micro LNBH29) for supplying
> > > voltage to Helene. This IC is controlled by I2C.
> > >
> > > The standard (ARIB STD-B21) says DC 15V power is needed to drive the
> > > converter (BS freq -> BS-IF freq) of BS dish antenna. This power
> > > can be supplied via antenna line.
> > >
> > > It seems,
> > > LNBH29 --(LNB_PWR)--> Helene --> BS antenna
> > >
> > > I don't know enough about Helene, but it maybe supply 15V power to
> > > converter of BS dish via antenna line if it receive 15V LNB_PWR...
> > >
> > >
> > > I don't have idea about controlling this IC. Should I write some
> > > driver for LNBH29, and pass the phandle to demodulator via device
> > > tree??
> > >
> > >
> > > > >
> > > > >
> > > > > >
> > > > > > Anyway, I changed the error print message to be clearer, displaying
> > > > > > instead:
> > > > > >
> > > > > > ERROR FE_SET_VOLTAGE: driver doesn't support it!
> > > > > >
> > > > >
> > > > > It's nice for users. Thanks!
> > > > >
> > > > >
> > > > > > >
> > > > > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > > > > CAN_FEC_AUTO
> > > > > > > CAN_GUARD_INTERVAL_AUTO
> > > > > > > CAN_HIERARCHY_AUTO
> > > > > > > CAN_INVERSION_AUTO
> > > > > > > CAN_QAM_AUTO
> > > > > > > CAN_TRANSMISSION_MODE_AUTO
> > > > > > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > > > > > Supported delivery systems:
> > > > > > > [ISDBS]
> > > > > > > ISDBT
> > > > > > > Frequency range for the current standard:
> > > > > > > From: 470 MHz
> > > > > > > To: 2.07 GHz
> > > > > > > Step: 25.0 kHz
> > > > > > > Symbol rate ranges for the current standard:
> > > > > > > From: 0Bauds
> > > > > > > To: 0Bauds
> > > > > >
> > > > > > That seems a driver issue. The ISDB-S ops.info should be
> > > > > > filling both symbol_rate_min and symbol_rate_max.
> > > > > >
> > > > > > I suspect that both should be filled with 28860000.
> > > > > >
> > > > > > The dvb_frontend.c core might hardcode it, but, IMHO,
> > > > > > it is better to keep those information inside the
> > > > > > tuner/frontend ops.info.
> > > > > >
> > > > >
> > > > > Indeed, thank you for reviewing. I fixed my driver. It seems works fine.
> > > > >
> > > > > ----
> > > > > # utils/dvb/.libs/dvb-fe-tool -a 0
> > > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > > CAN_FEC_AUTO
> > > > > CAN_GUARD_INTERVAL_AUTO
> > > > > CAN_HIERARCHY_AUTO
> > > > > CAN_INVERSION_AUTO
> > > > > CAN_QAM_AUTO
> > > > > CAN_TRANSMISSION_MODE_AUTO
> > > > > DVB API Version 5.11, Current v5 delivery system: ISDBS
> > > > > Supported delivery systems:
> > > > > [ISDBS]
> > > > > ISDBT
> > > > > Frequency range for the current standard:
> > > > > From: 470 MHz
> > > > > To: 2.07 GHz
> > > > > Step: 25.0 kHz
> > > > > Symbol rate ranges for the current standard:
> > > > > From: 28.9 MBauds
> > > > > To: 28.9 MBauds
> > > > > SEC: set voltage to OFF
> > > > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > > > > ----
> > > >
> > > > That sounds ok.
> > > >
> > > > >
> > > > >
> > > > > > > SEC: set voltage to OFF
> > > > > > > ERROR FE_SET_VOLTAGE: Operation not permitted
> > > > > > >
> > > > > > >
> > > > > > > # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> > > > > > > Changing delivery system to: ISDBT
> > > > > > > ERROR FE_SET_VOLTAGE: Unknown error 524
> > > > > > >
> > > > > > > # ./utils/dvb/.libs/dvb-fe-tool
> > > > > > > Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> > > > > > > CAN_FEC_AUTO
> > > > > > > CAN_GUARD_INTERVAL_AUTO
> > > > > > > CAN_HIERARCHY_AUTO
> > > > > > > CAN_INVERSION_AUTO
> > > > > > > CAN_QAM_AUTO
> > > > > > > CAN_TRANSMISSION_MODE_AUTO
> > > > > > > DVB API Version 5.11, Current v5 delivery system: ISDBT
> > > > > > > Supported delivery systems:
> > > > > > > ISDBS
> > > > > > > [ISDBT]
> > > > > > > Frequency range for the current standard:
> > > > > > > From: 470 MHz
> > > > > > > To: 2.07 GHz
> > > > > > > Step: 25.0 kHz
> > > > > >
> > > > > > The rest looks OK for me.
> > > > > >
> > > > > > > > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > > > > > > > >
> > > > > > > > > .name = "Sony HELENE Ter tuner",
> > > > > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > > > > .frequency_max_hz = 1200 * MHz,
> > > > > > > > > .frequency_step_hz = 25 * kHz,
> > > > > > > > >
> > > > > > > > > .name = "Sony HELENE Sat tuner",
> > > > > > > > > .frequency_min_hz = 500 * MHz,
> > > > > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > > > > .frequency_step_hz = 1 * MHz,
> > > > > > > > >
> > > > > > > > > Is this better to add new info for both system?
> > > > > > > > >
> > > > > > > > > .name = "Sony HELENE Sat/Ter tuner",
> > > > > > > > > .frequency_min_hz = 1 * MHz,
> > > > > > > > > .frequency_max_hz = 2500 * MHz,
> > > > > > > > > .frequency_step_hz = 25 * kHz, // Is this
> correct...?
> > > > > > > >
> > > > > > > > That is indeed a very good question, and maybe a reason why we
> > > > > > > > may need other approaches.
> > > > > > > >
> > > > > > > > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > > > > > > > the frequency range should be ok. It would aget_frontend_algoctually
> be
> > > > > pretty
> > > > > > cool
> > > > > > > > to use a tuner with such wide range for SDR, if the hardware supports
> > > > > > > > raw I/Q collect :-D
> > > > > > > >
> > > > > > > > The frequency step is a different issue. If the tuner driver uses
> > > > > > > > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > > > > > > > this function is not defined), then the step will be used to adjust
> > > > > > > > the zigzag interactions. If it is too small, the tuning will lose
> > > > > > > > channels if the signal is not strong.
> > > > > > > >
> > > > > > >
> > > > > > > Thank you for describing. It's difficult problem...
> > > > > >
> > > > > > I double-checked the implementation. We don't need to worry about
> > > > > > zigzag, provided that the ISDB-S implementation at the core is correct.
> > > > > >
> > > > > > For satellite/cable standards, the zigzag logic takes the symbol
> > > > > > rate into account, and not the stepsize:
> > > > > >
> > > > > > case SYS_DVBS:
> > > > > > case SYS_DVBS2:
> > > > > > case SYS_ISDBS:
> > > > > > case SYS_TURBO:
> > > > > > case SYS_DVBC_ANNEX_A:
> > > > > > case SYS_DVBC_ANNEX_C:
> > > > > > fepriv->min_delay = HZ / 20;
> > > > > > fepriv->step_size = c->symbol_rate / 16000;
> > > > > > fepriv->max_drift = c->symbol_rate / 2000;
> > > > > > break;
> > > > > >
> > > > > > For terrestrial standards, it uses the stepsize:
> > > > > >
> > > > > > case SYS_DVBT:
> > > > > > case SYS_DVBT2:
> > > > > > case SYS_ISDBT:
> > > > > > case SYS_DTMB:
> > > > > > fepriv->min_delay = HZ / 20;
> > > > > > fepriv->step_size =
> dvb_frontend_get_stepsize(fe) *
> > > > 2;
> > > > > > fepriv->max_drift =
> (dvb_frontend_get_stepsize(fe)
> > > *
> > > > 2)
> > > > > +
> > > > > > 1;
> > > > > > break;
> > > > > >
> > > > > > So, having a value of 25 kHz there won't affect the zigzag algorithm
> > > > > > for ISDB-S, as it will be used only for ISDB-T.
> > > > > >
> > > > >
> > > > > Thank you for checking and describing. I checked it too.
> > > > >
> > > > > Default value is fine as you said, and we can use get_tune_settings()
> > > > > callback if we face the problem or need different settings for each
> > > > > delivery systems in the future.
> > > > >
> > > > > /* get frontend-specific tuning settings */
> > > > > memset(&fetunesettings, 0, sizeof(struct
> > > dvb_frontend_tune_settings));
> > > > > if (fe->ops.get_tune_settings && (fe->ops.get_tune_settings(fe,
> > > > > &fetunesettings) == 0)) {
> > > > > fepriv->min_delay = (fetunesettings.min_delay_ms * HZ) /
> 1000;
> > > > > fepriv->max_drift = fetunesettings.max_drift;
> > > > > fepriv->step_size = fetunesettings.step_size;
> > > > > } else {
> > > > > /* default values */
> > > > > ...
> > > >
> > > > Sure.
> > > >
> > > > >
> > > > >
> > > > > > > > In the specific case of helene, it doesn't have a get_frontend_algo,
> > > > > > > > so it will use the step frequency.
> > > > > > > >
> > > > > > > > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > > > > > > > here, if helene does sigzag in hardware or not.
> > > > > > > >
> > > > > > >
> > > > > > > As far as I know, Helene does not have automatic scan mechanism in
> > > > > > > hardware.
> > > > > >
> > > > > > Ok, so the driver is doing the right thing here.
> > > > > >
> > > > > > > > If it does in hardware, you could add a get_frontend_algo() routine
> > > > > > > > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > > > > > > > algorithm in the Kernel will stop, as it will rely at the hardware.
> > > > > > > >
> > > > > > > > Please notice that, if the hardware doesn't do zigzag itself, this
> > > > > > > > will make it lose channels. On the other hand, if the hardware does
> > > > > > > > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > > > > > > > Kernel won't try to do sigzag itself.
> > > > > > > >
> > > > > > >
> > > > > > > ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> > > > > > > BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> > > > > > > ISDB-T system and 25kHz is small for ISDB-S system.
> > > > > >
> > > > > > Yeah, but, after double-checking the logic, for ISDB-S, it will
> > > > > > use:
> > > > > >
> > > > > > c->symbol_rate = 28860000;
> > > > > > c->rolloff = ROLLOFF_35;
> > > > > > c->bandwidth_hz = c->symbol_rate / 100 * 135;
> > > > > >
> > > > > > That would actually set the ISDB-S channel separation to 38.961 MHz.
> > > > > >
> > > > > > By setting symbol_rate like that, the zigzag for ISDB-S will
> > > > > > be defined by:
> > > > > >
> > > > > > fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000
> =
> > > > > .002435
> > > > > > - e. g. steps of ~25 kHz */
> > > > > > fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000
> =
> > > > > .0194805
> > > > > > - e. g. max drift of ~195 kHz */
> > > > > >
> > > > > > Funny enough, it will be using about 25 kHz as step size for ISDB-S.
> > > > > >
> > > > > > I have no idea if the ISDB-S standard defines the zigzag logic,
> > > > > > but I would be expecting a higher value for it. So, perhaps
> > > > > > the ISDB-S zigzag could be optimized.
> > > > > >
> > > > > > Thanks,
> > > > > > Mauro
> > > > >
> > > > > Hmm, interesting. I don't know zigzag for ISDB-S too, sorry...
> > > > >
> > > > > Anyway, I don't worry about that. I said in above, we can use
> > > > > get_tune_settings() for fine tuning.
> > > > >
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Katsuhiro Suzuki
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> >
> >
> >
>
>
>
>
> Cheers,
> Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-07-18 0:39 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-21 3:17 [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver Katsuhiro Suzuki
2018-07-04 16:58 ` Mauro Carvalho Chehab
2018-07-05 1:58 ` Katsuhiro Suzuki
2018-07-05 2:42 ` Mauro Carvalho Chehab
2018-07-05 5:43 ` Katsuhiro Suzuki
2018-07-06 0:27 ` Mauro Carvalho Chehab
2018-07-06 6:04 ` Katsuhiro Suzuki
2018-07-06 11:16 ` Mauro Carvalho Chehab
2018-07-09 2:04 ` Katsuhiro Suzuki
2018-07-09 13:59 ` Mauro Carvalho Chehab
2018-07-10 2:50 ` Katsuhiro Suzuki
2018-07-17 6:07 ` Katsuhiro Suzuki
2018-07-17 10:58 ` Mauro Carvalho Chehab
2018-07-18 0:39 ` Katsuhiro Suzuki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).