Em Mon, 9 May 2016 13:59:52 +0000 Ramesh Shanmugasundaram <ramesh.shanmugasundaram@xxxxxxxxxxxxxx> escreveu: > Hi Mauro, > > Thanks for the clarifications. > > > Ramesh Shanmugasundaram <ramesh.shanmugasundaram@xxxxxxxxxxxxxx> 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
