Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp224633imm; Tue, 17 Jul 2018 17:40:14 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdCCkJoilVUYihwNc4SG3W3Zoo9cw0Xx8fIglKsAvuUab2l4zSQkhR4gOkWmSqoXDJBdw2U X-Received: by 2002:a17:902:546:: with SMTP id 64-v6mr3720341plf.232.1531874414891; Tue, 17 Jul 2018 17:40:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531874414; cv=none; d=google.com; s=arc-20160816; b=kDnMggduywYGoTNsAJW9gveWbnkB1ZgoYHxrNsv5RE1XASUlkw4r0pDvpAQtlIutXQ TMQTXreT7bUzV7mUnidC6JM+7xO9oz659jYrxlu6ZbJ5T/Hc/RCaHl9Ve5FTAteWf1Y6 HHEc6/tk4uTim1gWVtBExYJ2Q92PrB+KyytVcFaeodg5RWAGn+du3W+WjKFDLctD4Evt FZr43ALa9AgQRYQu2d9zfwXN/dHOZKxFev/Z+T42lIU5I8Dp/DRUtdyWSdgBvWrP8EmN RY8a04aFjf9Q4NDZ0M395YrD4PvlAtymV/2HW9LPzchXK62JdLnb/IpOXYOvo5CS5UdB 08pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:arc-authentication-results; bh=obk/qVueyRQrItPdT1bZ+0YoMIYuPwhWhefjJcLppmg=; b=OUt8haKsHjZVyd4CX3KQm+HYiRlhMaB3ldnT65qo0hKeBhRWMwXDUvOish5aMESbZX qDQPSgUhBm3GUnqfbQh+gHZy70e+Rpbnd588AVGpJkhGe/j2TCUYGMs6e2oYKx+7oUkq X1bK0WjczYPDCz8eDIxT7OyVomz7R2mGk7l8sgSeKA9hqTTgEeItl36rkRv9th3sw8PQ VcKtaEy7fblsXuaODWx3l2Lfb3NwO4ALIqlL87D2jggiFqv2jKmsXI15S1stuPENffb0 LfU5Kec5qYa5qpA0Jqrr1EXmpPghn2BlcbtmLLl5SoCeA0/aqxYmmTeVfSzP7As48/Em 0Jng== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b25-v6si2035452pgf.545.2018.07.17.17.39.58; Tue, 17 Jul 2018 17:40:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731205AbeGRBOd convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Jul 2018 21:14:33 -0400 Received: from mx.socionext.com ([202.248.49.38]:15872 "EHLO mx.socionext.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729934AbeGRBOd (ORCPT ); Tue, 17 Jul 2018 21:14:33 -0400 Received: from unknown (HELO kinkan-ex.css.socionext.com) ([172.31.9.52]) by mx.socionext.com with ESMTP; 18 Jul 2018 09:39:21 +0900 Received: from mail.mfilter.local (m-filter-1 [10.213.24.61]) by kinkan-ex.css.socionext.com (Postfix) with ESMTP id E30E8180B7D; Wed, 18 Jul 2018 09:39:21 +0900 (JST) Received: from 172.31.9.53 (172.31.9.53) by m-FILTER with ESMTP; Wed, 18 Jul 2018 09:39:21 +0900 Received: from yuzu.css.socionext.com (yuzu [172.31.8.45]) by iyokan.css.socionext.com (Postfix) with ESMTP id B716A4039E; Wed, 18 Jul 2018 09:39:21 +0900 (JST) Received: from DESKTOPFLNNJ4T (unknown [10.213.132.95]) by yuzu.css.socionext.com (Postfix) with ESMTP id 8AD0F120424; Wed, 18 Jul 2018 09:39:21 +0900 (JST) From: "Katsuhiro Suzuki" To: "'Mauro Carvalho Chehab'" , =?utf-8?B?U3V6dWtpLCBLYXRzdWhpcm8v6Yi05pyoIOWLneWNmg==?= Cc: , "Masami Hiramatsu" , "Jassi Brar" , , , "Abylay Ospan" References: <20180621031748.21703-1-suzuki.katsuhiro@socionext.com> <20180704135657.3fd607cb@coco.lan> <000401d41403$b33db490$19b91db0$@socionext.com> <20180704234244.32d20f6b@coco.lan> <000501d41423$265013a0$72f03ae0$@socionext.com> <20180705212723.2856f064@coco.lan> <001f01d414ef$27145450$753cfcf0$@socionext.com> <20180706081603.2d8451c9@coco.lan> <002c01d41729$2ff6fa00$8fe4ee00$@socionext.com> <20180709105938.3d2f8391@coco.lan> <004501d417f8$c83a01c0$58ae0540$@socionext.com> <001201d41d94$7370e1d0$5a52a570$@socionext.com> <20180717195853.07b2b42b@vela.lan> In-Reply-To: <20180717195853.07b2b42b@vela.lan> Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver Date: Wed, 18 Jul 2018 09:39:18 +0900 Message-ID: <001301d41e2f$c3169400$4943bc00$@socionext.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHUCQ54MjjlTBc86EWbqPvQU8s0kqR+x14AgAEazrD//4iKAIAAt4VggAC0/4CAAOtEYP//yfiAgASmiHCAAD4rAIABTszAgAtQ3LD//8B+gAAvczHw Content-Language: ja x-securitypolicycheck: OK by SHieldMailChecker v2.5.2 x-shieldmailcheckerpolicyversion: POLICY180220 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mauro, > -----Original Message----- > From: Mauro Carvalho Chehab > Sent: Tuesday, July 17, 2018 7:59 PM > To: Suzuki, Katsuhiro/鈴木 勝博 > Cc: linux-media@vger.kernel.org; Masami Hiramatsu ; > Jassi Brar ; linux-arm-kernel@lists.infradead.org; > linux-kernel@vger.kernel.org; Abylay Ospan > 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" 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 > > > Sent: Tuesday, July 10, 2018 11:51 AM > > > To: 'Mauro Carvalho Chehab' ; Suzuki, Katsuhiro/ > 鈴木 > > > 勝博 > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu > ; > > > Jassi Brar ; > linux-arm-kernel@lists.infradead.org; > > > linux-kernel@vger.kernel.org; Abylay Ospan > > > Subject: Re: [PATCH v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T > > > demodulator driver > > > > > > Hello Mauro, > > > > > > > -----Original Message----- > > > > From: Mauro Carvalho Chehab > > > > Sent: Monday, July 9, 2018 11:00 PM > > > > To: Suzuki, Katsuhiro/鈴木 勝博 > > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu > > > ; > > > > Jassi Brar ; > linux-arm-kernel@lists.infradead.org; > > > > linux-kernel@vger.kernel.org; Abylay Ospan > > > > 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" escreveu: > > > > > > > > > Hello Mauro, > > > > > > > > > > > -----Original Message----- > > > > > > From: linux-media-owner@vger.kernel.org > > > > > On > > > > > > Behalf Of Mauro Carvalho Chehab > > > > > > Sent: Friday, July 6, 2018 8:16 PM > > > > > > To: Suzuki, Katsuhiro/鈴木 勝博 > > > > > > Cc: linux-media@vger.kernel.org; Masami Hiramatsu > > > > > ; > > > > > > Jassi Brar ; > > > > linux-arm-kernel@lists.infradead.org; > > > > > > linux-kernel@vger.kernel.org; Abylay Ospan > > > > > > 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" 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