V4L2 SDR compliance test?

V4L2 SDR compliance test?

[Ramesh Shanmugasundaram]

Hi Maintainers, All,

Renesas R-Car SoCs have Digital Radio Interface (DRIF) controllers. They are 
receive only SPI slave modules that support I2S format. The targeted
application of these controllers is SDR.

While evaluating the V4L2 SDR framework for this controller, we noticed the 
compliance test demands TUNER ioctls for SDR device. As a SoC controller,
DRIF is independent of tuner functionality as a third party provides this
device. The DRIF driver will support V4L2_CID_xxx & V4L2_SDR_FMT_xxx ioctls
but not the tuner ioctls.

Two possible cases:
-------------------
1) Third party tuner driver
	- The framework does provide support to register tuner as a subdev
and can be bound to the SDR device using notifier callbacks

2) User space Tuner app 
	- We also have cases where the tuner s/w logic can be a vendor
supplied user space application or library that talks to the chip using generic
system calls - like i2c read/writes.

The DRIF driver code as such will have v4l2_async_notifier_register only to be
informed if a tuner device attaches. But this may or may not happen
depending on the target board.

>From upstream V4L2 SDR driver perspective, these DRIF patches will FAIL
V4L2 compliance tests (a criteria needed to submit fresh driver patches).

Questions are 
1) Is this approach acceptable to the maintainers?
2) Should the SDR compliance tests be updated for these evolving use cases?
------------------

Thanks,
Ramesh

RE: V4L2 SDR compliance test?

[Ramesh Shanmugasundaram]

Hi Mauro,

Thanks for the clarifications.

> Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com> escreveu:
> 
> > Hi Maintainers, All,
> >
> > Renesas R-Car SoCs have Digital Radio Interface (DRIF) controllers.
> > They are receive only SPI slave modules that support I2S format. The 
> > targeted application of these controllers is SDR.
[...]
> > Two possible cases:
> > -------------------
> > 1) Third party tuner driver
> > 	- The framework does provide support to register tuner as a subdev 
> > and can be bound to the SDR device using notifier callbacks
> 
> Tuner is usually an i2c subdev, visible by the main SDR driver. No 
> problem
> here: the main driver should use the subdev callbacks to direct the 
> tuner- specific ioctls to the tuner subdev.

Yes. The main SDR driver can have code to direct tuner subdev.
 
> 
> > 2) User space Tuner app
> > 	- We also have cases where the tuner s/w logic can be a vendor 
> > supplied user space application or library that talks to the chip 
> > using generic system calls - like i2c read/writes.
> 
> Well, an userspace tuner app is out of the Kernel tree, so I can't see 
> how it would affect it: it can have whatever API it needs (or even no 
> API at all). Of course, in this case, the performance will very likely 
> be worse, as the SDR data should also be handled in userspace.
> 
> If, for performance issues, it would require a faster I/O, then such 
> tuner app should be converted to be a Kernel driver. Usually, it is 
> not hard to convert those drivers to Kernelspace, as typically it is 
> just a bunch of registers that should be set to make it to tune into 
> an specific frequency and to adjust the tuner filters to the desired 
> bandwidth and modulation type, in order to improve noise rejection.

Yes, this is possible. However, this is Tuner chip vendor's decision (NDA, license issues etc.) and it is not in our control.

As mentioned above, we can have the main SDR (DRIF) driver code to direct tuner subdev if present. However, when we want to upstream the DRIF driver we may not have a real Tuner driver/device to get the compliance test results. Should we run the compliance tests with a dummy stubbed tuner subdev? 

Please do suggest how to proceed in this case? 

Thanks,
Ramesh

Re: V4L2 SDR compliance test?

[Mauro Carvalho Chehab]

Em Mon, 9 May 2016 13:59:52 +0000
Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com> escreveu:

> Hi Mauro,
> 
> Thanks for the clarifications.
> 
> > Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com> escreveu:
> >   
> > > Hi Maintainers, All,
> > >
> > > Renesas R-Car SoCs have Digital Radio Interface (DRIF) controllers.
> > > They are receive only SPI slave modules that support I2S format. The 
> > > targeted application of these controllers is SDR.  
> [...]
> > > Two possible cases:
> > > -------------------
> > > 1) Third party tuner driver
> > > 	- The framework does provide support to register tuner as a subdev 
> > > and can be bound to the SDR device using notifier callbacks  
> > 
> > Tuner is usually an i2c subdev, visible by the main SDR driver. No 
> > problem
> > here: the main driver should use the subdev callbacks to direct the 
> > tuner- specific ioctls to the tuner subdev.  
> 
> Yes. The main SDR driver can have code to direct tuner subdev.
>  
> >   
> > > 2) User space Tuner app
> > > 	- We also have cases where the tuner s/w logic can be a vendor 
> > > supplied user space application or library that talks to the chip 
> > > using generic system calls - like i2c read/writes.  
> > 
> > Well, an userspace tuner app is out of the Kernel tree, so I can't see 
> > how it would affect it: it can have whatever API it needs (or even no 
> > API at all). Of course, in this case, the performance will very likely 
> > be worse, as the SDR data should also be handled in userspace.
> > 
> > If, for performance issues, it would require a faster I/O, then such 
> > tuner app should be converted to be a Kernel driver. Usually, it is 
> > not hard to convert those drivers to Kernelspace, as typically it is 
> > just a bunch of registers that should be set to make it to tune into 
> > an specific frequency and to adjust the tuner filters to the desired 
> > bandwidth and modulation type, in order to improve noise rejection.  
> 
> Yes, this is possible. However, this is Tuner chip vendor's decision (NDA, license issues etc.) and it is not in our control.

True, but an independent tuner driver very likely can be written with very
little effort. All it requires is to monitor the traffic at the I2C bus
and to write a driver that reproduces it, identifying what part of the
I2C messages contain the frequency and enable/disable the filters.

We have several such drivers in the Kernel, and that's the procedure used
when the chipset vendor doesn't see the value of having his chipset used
by a Linux-based device.

> As mentioned above, we can have the main SDR (DRIF) driver code to direct tuner subdev if present. However, when we want to upstream the DRIF driver we may not have a real Tuner driver/device to get the compliance test results. Should we run the compliance tests with a dummy stubbed tuner subdev? 

No, an upstream requirement is to have everything tested on real hardware.
What I recommend you is to either convince the tuner provider to send
upstream a driver (or allow you to do so) or to switch to some other vendor
whose driver is already in the Kernel or sees the value of having his
chipset used on Linux.
 
> Please do suggest how to proceed in this case? 
> 

Regards,
Mauro

RE: V4L2 SDR compliance test?

[Ramesh Shanmugasundaram]

Hi Mauro,

> Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com> escreveu:
> 
> > Hi Mauro,
> >
> > Thanks for the clarifications.
> >
> > > Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
> escreveu:
> > >
> > > > Hi Maintainers, All,
> > > >
> > > > Renesas R-Car SoCs have Digital Radio Interface (DRIF) controllers.
> > > > They are receive only SPI slave modules that support I2S format.
> > > > The targeted application of these controllers is SDR.
[...]
> > > If, for performance issues, it would require a faster I/O, then such
> > > tuner app should be converted to be a Kernel driver. Usually, it is
> > > not hard to convert those drivers to Kernelspace, as typically it is
> > > just a bunch of registers that should be set to make it to tune into
> > > an specific frequency and to adjust the tuner filters to the desired
> > > bandwidth and modulation type, in order to improve noise rejection.
> >
> > Yes, this is possible. However, this is Tuner chip vendor's decision
> (NDA, license issues etc.) and it is not in our control.
> 
> True, but an independent tuner driver very likely can be written with very
> little effort. All it requires is to monitor the traffic at the I2C bus
> and to write a driver that reproduces it, identifying what part of the I2C
> messages contain the frequency and enable/disable the filters.

Yes, this is possible. 

> 
> We have several such drivers in the Kernel, and that's the procedure used
> when the chipset vendor doesn't see the value of having his chipset used
> by a Linux-based device.
> 
> > As mentioned above, we can have the main SDR (DRIF) driver code to
> direct tuner subdev if present. However, when we want to upstream the DRIF
> driver we may not have a real Tuner driver/device to get the compliance
> test results. Should we run the compliance tests with a dummy stubbed
> tuner subdev?
> 
> No, an upstream requirement is to have everything tested on real hardware.
> What I recommend you is to either convince the tuner provider to send
> upstream a driver (or allow you to do so) or to switch to some other
> vendor whose driver is already in the Kernel or sees the value of having
> his chipset used on Linux.

Yep, that is a clear mandate. We shall talk to Tuner vendor and decide accordingly.

Thanks for your time and inputs,
Ramesh