diff mbox series

[v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver

Message ID 20180621031748.21703-1-suzuki.katsuhiro@socionext.com
State Superseded
Headers show
Series [v3] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver | expand

Commit Message

Katsuhiro Suzuki June 21, 2018, 3:17 a.m. UTC
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

-- 
2.17.1

Comments

Mauro Carvalho Chehab July 4, 2018, 4:58 p.m. UTC | #1
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
Katsuhiro Suzuki July 5, 2018, 1:58 a.m. UTC | #2
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
Mauro Carvalho Chehab July 5, 2018, 2:42 a.m. UTC | #3
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
Katsuhiro Suzuki July 5, 2018, 5:43 a.m. UTC | #4
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
Mauro Carvalho Chehab July 6, 2018, 12:27 a.m. UTC | #5
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
Katsuhiro Suzuki July 6, 2018, 6:04 a.m. UTC | #6
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
Mauro Carvalho Chehab July 6, 2018, 11:16 a.m. UTC | #7
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
Katsuhiro Suzuki July 9, 2018, 2:04 a.m. UTC | #8
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
Mauro Carvalho Chehab July 9, 2018, 1:59 p.m. UTC | #9
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
Katsuhiro Suzuki July 10, 2018, 2:50 a.m. UTC | #10
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
Katsuhiro Suzuki July 17, 2018, 6:07 a.m. UTC | #11
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

>
Katsuhiro Suzuki July 18, 2018, 12:39 a.m. UTC | #12
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
diff mbox series

Patch

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, &regmap_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, &regmap_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 */