Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

[Guennadi Liakhovetski]

Hi Robert,

Not sure I understand, what should the purpose of this patch be? Why do 
you want to move some function(s) from one file to another? And you aren't 
even calling the new soc_mbus_build_fmts_xlate() function, and you aren't 
replacing the currently used analogous soc_camera_init_user_formats() 
function. Or was this patch not-to-be-reviewed?

Thanks
Guennadi

On Sat, 2 Apr 2016, Robert Jarzmik wrote:

> Transfer the formats translations to soc_mediabus. Even is soc_camera
> was to be deprecated, soc_mediabus will survive, and should describe all
> that happens on the bus connecting the image processing unit of the SoC
> and the sensor.
> 
> The translation engine provides an easy way to compute the formats
> available in the v4l2 device, given any sensors format capabilities
> bound with known image processing transformations.
> 
> Signed-off-by: Robert Jarzmik 
> ---
>  drivers/media/platform/soc_camera/soc_camera.c   |  7 +--
>  drivers/media/platform/soc_camera/soc_mediabus.c | 65 
> 
>  include/media/drv-intf/soc_mediabus.h| 22 
>  include/media/soc_camera.h   | 15 --
>  4 files changed, 88 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
> b/drivers/media/platform/soc_camera/soc_camera.c
> index 46c7186f7867..039524a20056 100644
> --- a/drivers/media/platform/soc_camera/soc_camera.c
> +++ b/drivers/media/platform/soc_camera/soc_camera.c
> @@ -204,12 +204,7 @@ static void soc_camera_clock_stop(struct soc_camera_host 
> *ici)
>  const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc(
>   struct soc_camera_device *icd, unsigned int fourcc)
>  {
> - unsigned int i;
> -
> - for (i = 0; i < icd->num_user_formats; i++)
> - if (icd->user_formats[i].host_fmt->fourcc == fourcc)
> - return icd->user_formats + i;
> - return NULL;
> + return soc_mbus_xlate_by_fourcc(icd->user_formats, fourcc);
>  }
>  EXPORT_SYMBOL(soc_camera_xlate_by_fourcc);
>  
> diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c 
> b/drivers/media/platform/soc_camera/soc_mediabus.c
> index e3e665e1c503..95c13055f50f 100644
> --- a/drivers/media/platform/soc_camera/soc_mediabus.c
> +++ b/drivers/media/platform/soc_camera/soc_mediabus.c
> @@ -10,6 +10,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -512,6 +513,70 @@ unsigned int soc_mbus_config_compatible(const struct 
> v4l2_mbus_config *cfg,
>  }
>  EXPORT_SYMBOL(soc_mbus_config_compatible);
>  
> +struct soc_camera_format_xlate *soc_mbus_build_fmts_xlate(
> + struct v4l2_device *v4l2_dev, struct v4l2_subdev *subdev,
> + int (*get_formats)(struct v4l2_device *, unsigned int,
> +struct soc_camera_format_xlate *xlate))
> +{
> + unsigned int i, fmts = 0, raw_fmts = 0;
> + int ret;
> + struct v4l2_subdev_mbus_code_enum code = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct soc_camera_format_xlate *user_formats;
> +
> + while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
> + raw_fmts++;
> + code.index++;
> + }
> +
> + /*
> +  * First pass - only count formats this host-sensor
> +  * configuration can provide
> +  */
> + for (i = 0; i < raw_fmts; i++) {
> + ret = get_formats(v4l2_dev, i, NULL);
> + if (ret < 0)
> + return ERR_PTR(ret);
> + fmts += ret;
> + }
> +
> + if (!fmts)
> + return ERR_PTR(-ENXIO);
> +
> + user_formats = kcalloc(fmts + 1, sizeof(*user_formats), GFP_KERNEL);
> + if (!user_formats)
> + return ERR_PTR(-ENOMEM);
> +
> + /* Second pass - actually fill data formats */
> + fmts = 0;
> + for (i = 0; i < raw_fmts; i++) {
> + ret = get_formats(v4l2_dev, i, user_formats + fmts);
> + if (ret < 0)
> + goto egfmt;
> + fmts += ret;
> + }
> + user_formats[fmts].code = 0;
> +
> + return user_formats;
> +egfmt:
> + kfree(user_formats);
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL(soc_mbus_build_fmts_xlate);
> +
> +const struct soc_camera_format_xlate *soc_mbus_xlate_by_fourcc(
> + struct soc_camera_format_xlate *user_formats, unsigned int fourcc)
> +{
> + unsigned int i;
> +
> + for (i = 0; user_formats[i].code; i++)
> + if (user_formats[i].host_fmt->fourcc == fourcc)
> + return user_formats + i;
> + return NULL;
> +}
> +EXPORT_SYMBOL(soc_mbus_xlate_by_fourcc);
> +
>  static int __init soc_mbus_init(void)
>  {
>   return 0;
> diff --git a/include/media/drv-intf/soc_mediabus.h 
> b/include/media/drv-intf/soc_mediabus.h
> index 2ff773785fb6..08af52f6338c 100644
> --- a/include/media/drv-intf/soc_mediabus.h
> +++ b/include/media/drv-intf/soc_mediabus.h
> @@ -95,6 +95,21 

Re: cron job: media_tree daily build: ERRORS

[Hans Verkuil]

On 04/05/2016 08:06 PM, Hans Verkuil wrote:

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Wed Apr  6 04:00:18 CEST 2016
git branch: test
git hash:   d3f5193019443ef8e556b64f3cd359773c4d377b
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3353-gcae47da
host hardware:  x86_64
host os:4.4.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-rc1-x86_64: ERRORS


This is caused by the CONFIG_KCOV option suddenly being enabled, which requires 
support for a particular
gcc option, which apparently my cross compiler doesn't have. I've temporarily 
disabled compiling this
kernel until I am back and can take a closer look at this.

Regards,

Hans



apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] au0828: remove unused macro

[Guennadi Liakhovetski]

An V4L2_CID_PRIVATE_SHARPNESS macro is defined in the su0828 driver, but 
never used. Remove it.

Signed-off-by: Guennadi Liakhovetski 
---
diff --git a/drivers/media/usb/au0828/au0828.h 
b/drivers/media/usb/au0828/au0828.h
index 23f869c..6871a21 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -54,7 +54,6 @@
 #define NTSC_STD_H  480
 
 #define AU0828_INTERLACED_DEFAULT   1
-#define V4L2_CID_PRIVATE_SHARPNESS  (V4L2_CID_PRIVATE_BASE + 0)
 
 /* Defination for AU0828 USB transfer */
 #define AU0828_MAX_ISO_BUFS12  /* maybe resize this value in the future */
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Wed Apr  6 04:00:18 CEST 2016
git branch: test
git hash:   d3f5193019443ef8e556b64f3cd359773c4d377b
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3353-gcae47da
host hardware:  x86_64
host os:4.4.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-rc1-x86_64: ERRORS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Security Fix for CVE-2015-7833

[Yuki Machida]

Hi Sasha,

I conformed that these patches for CVE-2015-7833 not applied at v4.1.20.
588afcc1c0e45358159090d95bf7b246fb67565
fa52bd506f274b7619955917abfde355e3d19ff
Could you please apply this CVE-2015-7833 fix for 4.1-stable ?

References:
https://security-tracker.debian.org/tracker/CVE-2015-7833
http://git.linuxtv.org/cgit.cgi/media_tree.git/commit?id=588afcc1c0e45358159090d95bf7b246fb67565
http://git.linuxtv.org/cgit.cgi/media_tree.git/commit?id=fa52bd506f274b7619955917abfde355e3d19ff

Regards,
Yuki Machida
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AVerMedia HD Volar (A867) AF9035 + MXL5007T driver issues

[Alessandro Radicati]

On Wed, Apr 6, 2016 at 12:33 AM, Antti Palosaari  wrote:
> I found one stick having AF9035 + MXL5007T. It is HP branded A867, so it
> should be similar. It seems to work all three 12.13.15.0 6.20.15.0
> firmwares:
> http://palosaari.fi/linux/v4l-dvb/firmware/af9035/
>
> mxl5007t 5-0060: creating new instance
> mxl5007t_get_chip_id: unknown rev (3f)
> mxl5007t_get_chip_id: MxL5007T detected @ 5-0060
>
> That is what AF9035 reports (with debug) as a chip version:
> dvb_usb_af9035: prechip_version=00 chip_version=03 chip_type=3802
>
>
> Do you have different chip version?
>

I have a Sky Italy DVB stick with the same chip version.  I see that
you get the 0x3f response as well... that should be fixed by the I2C
patch I proposed.  However, your stick seems to handle the read
properly and process subsequent I2C commands - something that doesn't
happen with mine.  The vendor drivers in linux and windows never seem
issue the USB I2C commands to read from the tuner.  I'll test with
other firmware versions to see if something changes.

Regards,
Alessandro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AVerMedia HD Volar (A867) AF9035 + MXL5007T driver issues

[Antti Palosaari]

I found one stick having AF9035 + MXL5007T. It is HP branded A867, so it 
should be similar. It seems to work all three 12.13.15.0 6.20.15.0 
firmwares:

http://palosaari.fi/linux/v4l-dvb/firmware/af9035/

mxl5007t 5-0060: creating new instance
mxl5007t_get_chip_id: unknown rev (3f)
mxl5007t_get_chip_id: MxL5007T detected @ 5-0060

That is what AF9035 reports (with debug) as a chip version:
dvb_usb_af9035: prechip_version=00 chip_version=03 chip_type=3802


Do you have different chip version?

regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] media: af9035 I2C combined write + read transaction fix

[Alessandro Radicati]

This patch will modify the af9035 driver to use the register address
fields of the I2C read command for the combined write/read transaction
case.  Without this change, the firmware issues just a I2C read transaction
without the preceding write transaction to select the register.

Signed-off-by: Alessandro Radicati 
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 2638e32..09a549b 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -367,10 +367,25 @@ static int af9035_i2c_master_xfer(struct i2c_adapter 
*adap,
memcpy([3], msg[0].buf, msg[0].len);
} else {
buf[1] = msg[0].addr << 1;
-   buf[2] = 0x00; /* reg addr len */
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
-   memcpy([5], msg[0].buf, msg[0].len);
+
+   /* Keep prev behavior for write req len > 2*/
+   if (msg[0].len > 2) {
+   buf[2] = 0x00; /* reg addr len */
+   memcpy([5], msg[0].buf, msg[0].len);
+
+   /* Use reg addr fields if write req len <= 2 */
+   } else {
+   req.wlen = 5;
+   buf[2] = msg[0].len;
+   if (msg[0].len == 2) {
+   buf[3] = msg[0].buf[0];
+   buf[4] = msg[0].buf[1];
+   } else if (msg[0].len == 1) {
+   buf[4] = msg[0].buf[0];
+   }
+   }
}
ret = af9035_ctrl_msg(d, );
}
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] media: soc_camera: rcar_vin: add device tree support for r8a7792

[Geert Uytterhoeven]

Hi Guennadi,

On Tue, Apr 5, 2016 at 10:56 PM, Guennadi Liakhovetski
 wrote:
> On Tue, 15 Mar 2016, Simon Horman wrote:
>> Simply document new compatibility string.
>> As a previous patch adds a generic R-Car Gen2 compatibility string
>> there appears to be no need for a driver updates.
>>
>> By documenting this compat string it may be used in DTSs shipped, for
>> example as part of ROMs. It must be used in conjunction with the Gen2
>> fallback compat string. At this time there are no known differences between
>> the r8a7792 IP block and that implemented by the driver for the Gen2
>> fallback compat string. Thus there is no need to update the driver as the
>> use of the Gen2 fallback compat string will activate the correct code in
>> the current driver while leaving the option for r8a7792-specific driver
>> code to be activated in an updated driver should the need arise.
>>
>> Signed-off-by: Simon Horman 
>> Acked-by: Geert Uytterhoeven 
>
> Strictly speaking, I see an ack from Geert to patch 1/2, but I don't see
> one for this patch 2/2. Have I missed it or did Geert mean to ack the
> whole series and forgot to mention that?

Sorry, apparently I replied with the "sting" comment and my ack to Simon only,
not to all.

Hence FTR:
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] media: soc_camera: rcar_vin: add device tree support for r8a7792

[Guennadi Liakhovetski]

Hi Simon,

On Tue, 15 Mar 2016, Simon Horman wrote:

> Simply document new compatibility string.
> As a previous patch adds a generic R-Car Gen2 compatibility string
> there appears to be no need for a driver updates.
> 
> By documenting this compat string it may be used in DTSs shipped, for
> example as part of ROMs. It must be used in conjunction with the Gen2
> fallback compat string. At this time there are no known differences between
> the r8a7792 IP block and that implemented by the driver for the Gen2
> fallback compat string. Thus there is no need to update the driver as the
> use of the Gen2 fallback compat string will activate the correct code in
> the current driver while leaving the option for r8a7792-specific driver
> code to be activated in an updated driver should the need arise.
> 
> Signed-off-by: Simon Horman 
> Acked-by: Geert Uytterhoeven 

Strictly speaking, I see an ack from Geert to patch 1/2, but I don't see 
one for this patch 2/2. Have I missed it or did Geert mean to ack the 
whole series and forgot to mention that?

Thanks
Guennadi

> ---
> v4
> * s/sting/string/ in changelog
> * Added Ack from Geert Uytterhoeven
> 
> v3
> * New patch
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 4266123888ed..6a4e61cbe011 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -9,6 +9,7 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7793" for the R8A7793 device
> +   - "renesas,vin-r8a7792" for the R8A7792 device
> - "renesas,vin-r8a7791" for the R8A7791 device
> - "renesas,vin-r8a7790" for the R8A7790 device
> - "renesas,vin-r8a7779" for the R8A7779 device
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AVerMedia HD Volar (A867) AF9035 + MXL5007T driver issues

[Alessandro Radicati]

On Tue, Apr 5, 2016 at 8:15 PM, Antti Palosaari  wrote:
> On 04/02/2016 01:44 PM, Alessandro Radicati wrote:
>>
>> Hi,
>> In trying to understand why my DVB USB tuner doesn't work with stock
>> kernel drivers (4.2.0), I decided to pull out my logic analyser and
>> sniff the I2C bus between the AF9035 and MXL5007T.  I seem to have
>> uncovered a couple of issues:
>>
>> 1) Attach fails because MXL5007T driver I2C soft reset fails.  This is
>> due to the preceding chip id read request that seems to hang the I2C
>> bus and cause subsequent I2C commands to fail.
>
>
> In my understanding MXL5007T register read is done in a two transactions.
> First you should write wanted register to register 0xfb. After that single
> byte read from the chip returns value for register configured to 0xfb.
> Write+read with repeated start is not supported and driver is buggy as it
> request that which usually leads to bogus value.
>

I'm not sure if it supports repeated start or not, but in reality the
AF9035 firmware will not perform a repeated start sequence.  I.e. a
single read USB command results in two separate I2C transactions (s
write ... p + s read ... p).  So using the specific I2C tuner read usb
command (with address fields) is the same as using two separate write
and read commands.  I've only tested default firmware version: LINK
12.13.15.0 - OFDM 6.20.15.0

>
>> 2) AF9035 driver I2C master xfer incorrectly implements "Write read"
>> case.  The FW expects register address fields to be used to send the
>> I2C writes for register selection.  The current implementation ignores
>> these fields and the result is that only an I2C read is issued.
>> Therefore the "0x3f" returned by the MXL5007T chip id query is not
>> from the expected register.  This is what is seen on the I2C bus:
>>
>> S | Read 0x60 + ACK | 0x3F + NAK | ...
>>
>> After which SDA is held low for ~6sec; reason for subsequent commands
>> failing.
>
>
> You should use "S | W | P | S | R | P", no "S | W | S | R | P" == write read
> with repeated start condition.
>

This is what I sniffed on the bus without any modifications to the
driver.  My intent was to show that there is no write transaction at
all.

>> 3) After modifying the AF9035 driver to fix point 2 and use the
>> register address field, the following is seen on the I2C bus:
>>
>> S | Write 0x60 + ACK | 0xFB + ACK | 0xD9 + ACK | P
>> S | Read 0x60 + ACK | 0x14 + NAK | ...
>
>
> That is correct sequence. You are trying to read more than 1 byte and it
> fails?
>

This is after I modified the driver to use the register address
fields.  Sequence looks good except for the missing P after the NAK,
but this is due to something holding SDA low or an issue with the
AF9035.  I've tested this reading other registers, but same behavior.
I've also tried using two separate write read commands, exact same I2C
sequence and same result.  I also hacked the driver to read two bytes
instead of one.  Interestingly I got 0x14 twice as expected, but again
the bus hangs after the NAK that marks the end of the read.

>> This time we get an expected response, but the I2C bus still hangs
>> with SDA held low and no Stop sequence.  It seems that the MXL5007T is
>> holding SDA low since the AF9035 happily cycles SCL trying to execute
>> the subsequent writes.  Without a solution to this, it seems that
>> avoiding the I2C read is the best way to have the driver work
>> correctly.  There are no other tuner reads so point 2 above becomes
>> moot for at least this device.
>>
>> Does anyone have any insight on the MXL5007T chip ID command and
>> whether it should be issued in certain conditions?  Any suggestions on
>> how to resolve this given the above?
>
>
> I tried to fix it earlier:
> http://www.spinics.net/lists/linux-media/msg62264.html
>
> Feel free to fix! It should not be very hard as you could even sniff data
> from the I2C bus directly. I don't have any AF9035+MXL5007T device, but I
> have tested it with older AF9015+MXL5007T.
>

So there are two problems:
1) AF9035 I2C master read function needs to use the register address
fields.  This is a trivial fix and I've done a patch.  However I'm
unsure of the consequences this may have with other tuners.  I can
only guess that tuner reads are almost never done or are not
important, otherwise this would have been caught earlier.  Again, this
may be something related to this specific firmware, but unlikely.
2) I2C bus hangs after any MXL5007t I2C read is performed.  I have no
idea why this happens, or who is the culprit.  I'm happy to test out
any suggestions.

Thanks,
Alessandro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AVerMedia HD Volar (A867) AF9035 + MXL5007T driver issues

[Antti Palosaari]

On 04/02/2016 01:44 PM, Alessandro Radicati wrote:

Hi,
In trying to understand why my DVB USB tuner doesn't work with stock
kernel drivers (4.2.0), I decided to pull out my logic analyser and
sniff the I2C bus between the AF9035 and MXL5007T.  I seem to have
uncovered a couple of issues:

1) Attach fails because MXL5007T driver I2C soft reset fails.  This is
due to the preceding chip id read request that seems to hang the I2C
bus and cause subsequent I2C commands to fail.


In my understanding MXL5007T register read is done in a two 
transactions. First you should write wanted register to register 0xfb. 
After that single byte read from the chip returns value for register 
configured to 0xfb. Write+read with repeated start is not supported and 
driver is buggy as it request that which usually leads to bogus value.




2) AF9035 driver I2C master xfer incorrectly implements "Write read"
case.  The FW expects register address fields to be used to send the
I2C writes for register selection.  The current implementation ignores
these fields and the result is that only an I2C read is issued.
Therefore the "0x3f" returned by the MXL5007T chip id query is not
from the expected register.  This is what is seen on the I2C bus:

S | Read 0x60 + ACK | 0x3F + NAK | ...

After which SDA is held low for ~6sec; reason for subsequent commands failing.


You should use "S | W | P | S | R | P", no "S | W | S | R | P" == write 
read with repeated start condition.



3) After modifying the AF9035 driver to fix point 2 and use the
register address field, the following is seen on the I2C bus:

S | Write 0x60 + ACK | 0xFB + ACK | 0xD9 + ACK | P
S | Read 0x60 + ACK | 0x14 + NAK | ...


That is correct sequence. You are trying to read more than 1 byte and it 
fails?



This time we get an expected response, but the I2C bus still hangs
with SDA held low and no Stop sequence.  It seems that the MXL5007T is
holding SDA low since the AF9035 happily cycles SCL trying to execute
the subsequent writes.  Without a solution to this, it seems that
avoiding the I2C read is the best way to have the driver work
correctly.  There are no other tuner reads so point 2 above becomes
moot for at least this device.

Does anyone have any insight on the MXL5007T chip ID command and
whether it should be issued in certain conditions?  Any suggestions on
how to resolve this given the above?


I tried to fix it earlier:
http://www.spinics.net/lists/linux-media/msg62264.html

Feel free to fix! It should not be very hard as you could even sniff 
data from the I2C bus directly. I don't have any AF9035+MXL5007T device, 
but I have tested it with older AF9015+MXL5007T.


regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 0/5] Media Device Allocator API

[Mauro Carvalho Chehab]

Em Tue, 5 Apr 2016 08:10:11 +0200
Takashi Iwai  escreveu:

> On Tue, 05 Apr 2016 05:35:55 +0200,
> Shuah Khan wrote:
> > 
> > There are known problems with media device life time management. When media
> > device is released while an media ioctl is in progress, ioctls fail with
> > use-after-free errors and kernel hangs in some cases.
> > 
> > Media Device can be in any the following states:
> > 
> > - Allocated
> > - Registered (could be tied to more than one driver)
> > - Unregistered, not in use (media device file is not open)
> > - Unregistered, in use (media device file is not open)
> > - Released
> > 
> > When media device belongs to  more than one driver, registrations should be
> > tracked to avoid unregistering when one of the drivers does unregister. A 
> > new
> > num_drivers field in the struct media_device covers this case. The media 
> > device
> > should be unregistered only when the last unregister occurs with num_drivers
> > count zero.
> > 
> > When a media device is in use when it is unregistered, it should not be
> > released until the application exits when it detects the unregistered
> > status. Media device that is in use when it is unregistered is moved to
> > to_delete_list. When the last unregister occurs, media device is 
> > unregistered
> > and becomes an unregistered, still allocated device. Unregister marks the
> > device to be deleted.
> > 
> > When media device belongs to more than one driver, as both drivers could be
> > unbound/bound, driver should not end up getting stale media device that is
> > on its way out. Moving the unregistered media device to to_delete_list helps
> > this case as well.
> > 
> > I ran bind/unbind loop tests on uvcvideo, au0828, and snd-usb-audio while
> > running application that does ioctls. Didn't see any use-after-free errors
> > on media device. A couple of known issues seen:
> > 
> > 1. When application exits, cdev_put() gets called after media device is
> >released. This is a known issue to resolve and Media Device Allocator
> >can't solve this one.
> > 2. When au0828 module is removed and then ioctls fail when cdev_get() looks
> >for the owning module as au0828 is very often the module that owns the
> >media devnode. This is a cdev related issue that needs to be resolved and
> >Media Device Allocator can't solve this one.
> > 
> > Shuah Khan (5):
> >   media: Add Media Device Allocator API
> >   media: Add driver count to keep track of media device registrations
> >   media: uvcvideo change to use Media Device Allocator API
> >   media: au0828 change to use Media Device Allocator API
> >   sound/usb: Use Media Controller API to share media resources  
> 
> I don't think we need to include usb-audio patch at this stage yet.

I agree. Let's first fix MC races first, then address the multi-driver
issues. Only after having those fixed, we should look at the sound/usb
patch.

Ok, we could keep it on some testing tree, but, IMHO,  it doesn't make any
sense to submit it to review, while the core is not fixed.

> The most important thing for now is to improve / stabilize the API
> itself so that other drivers can use it as is.  Once when the API is
> really stabilized, we create a solid git branch that may be based for
> multiple subsystems, and I'll merge usb-audio stuff through sound git
> tree.

Works for me. After we have this properly fixed and stabilized on media,
I'll pass you a stable topic branch for you. This way, you can test a
new version of the sound/usb patch and apply on your tree when it fits
well for you.

> 
> Also, the previous usb-audio MC implementation had a few serious bugs,
> including quirk NULL dereference.  See the bugzilla below for some fix
> patches to 4.6-rc1:
>   https://bugzilla.kernel.org/show_bug.cgi?id=115561
> Feel free to fold them in, if they are still valid.
> 
> 
> thanks,
> 
> Takashi


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [media 5/5] Bridge driver for PT3, PX-Q3PE & PX-BCUD

[Mauro Carvalho Chehab]

Em Wed, 6 Apr 2016 01:14:14 +0900
 escreveu:

> From: Буди Романто, AreMa Inc 
> 
> Bridge driver for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards & PX-BCUD 
> ISDB-S USB dongle.
> Including simplified Nagahama's patch for PLEX PX-BCUD (ISDB-S usb dongle)...
> Please read cover letter for details.

This is not a full patch review. As I said before, the right procedure is
to modify the existing drivers and not replace them by some other driver.

So, I'll wait for you to take the right approach to review, as otherwise
it is impossible to see if this would cause regressions.

Yet, I'd like to add some quick notes. See below.

> 
> Signed-off-by: Буди Романто, AreMa Inc 
> ---
>  drivers/media/Kconfig   |   5 +-
>  drivers/media/pci/Kconfig   |   2 +-
>  drivers/media/pci/Makefile  |   2 +-
>  drivers/media/pci/ptx/Kconfig   |  23 ++
>  drivers/media/pci/ptx/Makefile  |   6 +
>  drivers/media/pci/ptx/pt3.c | 426 +++
>  drivers/media/pci/ptx/ptx_common.c  | 266 +++
>  drivers/media/pci/ptx/ptx_common.h  |  76 +
>  drivers/media/pci/ptx/pxq3pe.c  | 588 
> 
>  drivers/media/usb/em28xx/Kconfig|   3 +
>  drivers/media/usb/em28xx/Makefile   |   1 +
>  drivers/media/usb/em28xx/em28xx-cards.c |  27 ++
>  drivers/media/usb/em28xx/em28xx-dvb.c   |  81 -
>  drivers/media/usb/em28xx/em28xx.h   |   1 +

Please split em28xx changes from PT3 PCI driver changes.

>  14 files changed, 1502 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/media/pci/ptx/Kconfig
>  create mode 100644 drivers/media/pci/ptx/Makefile
>  create mode 100644 drivers/media/pci/ptx/pt3.c
>  create mode 100644 drivers/media/pci/ptx/ptx_common.c
>  create mode 100644 drivers/media/pci/ptx/ptx_common.h
>  create mode 100644 drivers/media/pci/ptx/pxq3pe.c
> 
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index a8518fb..37fae59 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -149,7 +149,10 @@ config DVB_NET
> You may want to disable the network support on embedded devices. If
> unsure say Y.
>  
> -# This Kconfig option is used by both PCI and USB drivers
> +# Options used by both PCI and USB drivers
> +config DVB_PTX_COMMON
> + tristate
> +

No, this approach looks wrong, and will cause build troubles depending on
the options the user is selecting.

>  config TTPCI_EEPROM
>   tristate
>   depends on I2C
> diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
> index 48a611b..9d63ad6 100644
> --- a/drivers/media/pci/Kconfig
> +++ b/drivers/media/pci/Kconfig
> @@ -44,7 +44,7 @@ source "drivers/media/pci/b2c2/Kconfig"
>  source "drivers/media/pci/pluto2/Kconfig"
>  source "drivers/media/pci/dm1105/Kconfig"
>  source "drivers/media/pci/pt1/Kconfig"
> -source "drivers/media/pci/pt3/Kconfig"
> +source "drivers/media/pci/ptx/Kconfig"
>  source "drivers/media/pci/mantis/Kconfig"
>  source "drivers/media/pci/ngene/Kconfig"
>  source "drivers/media/pci/ddbridge/Kconfig"
> diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
> index 5f8aacb..984e37c 100644
> --- a/drivers/media/pci/Makefile
> +++ b/drivers/media/pci/Makefile
> @@ -7,7 +7,7 @@ obj-y+=   ttpci/  \
>   pluto2/ \
>   dm1105/ \
>   pt1/\
> - pt3/\
> + ptx/\
>   mantis/ \
>   ngene/  \
>   ddbridge/   \
> diff --git a/drivers/media/pci/ptx/Kconfig b/drivers/media/pci/ptx/Kconfig
> new file mode 100644
> index 000..53ec5ea
> --- /dev/null
> +++ b/drivers/media/pci/ptx/Kconfig
> @@ -0,0 +1,23 @@
> +config DVB_PT3
> + tristate "Earthsoft PT3 cards"
> + depends on DVB_CORE && PCI && I2C
> + select DVB_PTX_COMMON
> + select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
> + select MEDIA_TUNER_QM1D1C004X if MEDIA_SUBDRV_AUTOSELECT
> + select MEDIA_TUNER_MXL301RF if MEDIA_SUBDRV_AUTOSELECT
> + help
> +   Support for Earthsoft PT3 ISDB-S/T PCIe cards.
> +
> +   Say Y or M if you own such a device and want to use it.
> +
> +config DVB_PXQ3PE
> + tristate "PLEX PX-Q3PE cards"
> + depends on DVB_CORE && PCI && I2C
> + select DVB_PTX_COMMON
> + select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
> + select MEDIA_TUNER_QM1D1C004X if MEDIA_SUBDRV_AUTOSELECT
> + select MEDIA_TUNER_MXL301RF if MEDIA_SUBDRV_AUTOSELECT
> + help
> +   Support for PLEX PX-Q3PE ISDB-S/T PCIe cards.
> +
> +   Say Y or M if you own such a device and want to use it.
> diff --git a/drivers/media/pci/ptx/Makefile b/drivers/media/pci/ptx/Makefile
> new file mode 100644
> index 000..9c41328
> --- /dev/null
> +++ b/drivers/media/pci/ptx/Makefile
> @@ -0,0 +1,6 @@
> 

Re: [media 2/5] drop backstabbing drivers

[Mauro Carvalho Chehab]

Em Wed, 6 Apr 2016 01:14:11 +0900
 escreveu:

> From: Буди Романто, AreMa Inc 

You should, instead, add the stuff you need to the existing drivers and not
remove them.

> Obsoleted & superseded, please read cover letter for details.

Cover letter is not stored at the git history. So, it should be used
with care, to just help reviewers to see the hole picture, but not
to describe the patches themselves.

So, if there are important information out there, required to understand
why/what/how a patch is needed, this should be moved into the patch 
descriptions and not being kept only at the cover letter.


Regards,
Mauro


> 
> Signed-off-by: Буди Романто, AreMa Inc 
> ---
>  drivers/media/dvb-frontends/tc90522.c | 840 
>  drivers/media/dvb-frontends/tc90522.h |  42 --
>  drivers/media/pci/pt3/Kconfig |  10 -
>  drivers/media/pci/pt3/Makefile|   8 -
>  drivers/media/pci/pt3/pt3.c   | 874 
> --
>  drivers/media/pci/pt3/pt3.h   | 186 
>  drivers/media/pci/pt3/pt3_dma.c   | 225 -
>  drivers/media/pci/pt3/pt3_i2c.c   | 240 --
>  drivers/media/tuners/mxl301rf.c   | 349 --
>  drivers/media/tuners/mxl301rf.h   |  26 -
>  drivers/media/tuners/qm1d1c0042.c | 448 -
>  drivers/media/tuners/qm1d1c0042.h |  37 --
>  12 files changed, 3285 deletions(-)
>  delete mode 100644 drivers/media/dvb-frontends/tc90522.c
>  delete mode 100644 drivers/media/dvb-frontends/tc90522.h
>  delete mode 100644 drivers/media/pci/pt3/Kconfig
>  delete mode 100644 drivers/media/pci/pt3/Makefile
>  delete mode 100644 drivers/media/pci/pt3/pt3.c
>  delete mode 100644 drivers/media/pci/pt3/pt3.h
>  delete mode 100644 drivers/media/pci/pt3/pt3_dma.c
>  delete mode 100644 drivers/media/pci/pt3/pt3_i2c.c
>  delete mode 100644 drivers/media/tuners/mxl301rf.c
>  delete mode 100644 drivers/media/tuners/mxl301rf.h
>  delete mode 100644 drivers/media/tuners/qm1d1c0042.c
>  delete mode 100644 drivers/media/tuners/qm1d1c0042.h
> 
> diff --git a/drivers/media/dvb-frontends/tc90522.c 
> b/drivers/media/dvb-frontends/tc90522.c
> deleted file mode 100644
> index 31cd325..000
> --- a/drivers/media/dvb-frontends/tc90522.c
> +++ /dev/null
> @@ -1,840 +0,0 @@
> -/*
> - * Toshiba TC90522 Demodulator
> - *
> - * Copyright (C) 2014 Akihiro Tsukada 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation version 2.
> - *
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - */
> -
> -/*
> - * NOTICE:
> - * This driver is incomplete and lacks init/config of the chips,
> - * as the necessary info is not disclosed.
> - * It assumes that users of this driver (such as a PCI bridge of
> - * DTV receiver cards) properly init and configure the chip
> - * via I2C *before* calling this driver's init() function.
> - *
> - * Currently, PT3 driver is the only one that uses this driver,
> - * and contains init/config code in its firmware.
> - * Thus some part of the code might be dependent on PT3 specific config.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include "dvb_math.h"
> -#include "tc90522.h"
> -
> -#define TC90522_I2C_THRU_REG 0xfe
> -
> -#define TC90522_MODULE_IDX(addr) (((u8)(addr) & 0x02U) >> 1)
> -
> -struct tc90522_state {
> - struct tc90522_config cfg;
> - struct dvb_frontend fe;
> - struct i2c_client *i2c_client;
> - struct i2c_adapter tuner_i2c;
> -
> - bool lna;
> -};
> -
> -struct reg_val {
> - u8 reg;
> - u8 val;
> -};
> -
> -static int
> -reg_write(struct tc90522_state *state, const struct reg_val *regs, int num)
> -{
> - int i, ret;
> - struct i2c_msg msg;
> -
> - ret = 0;
> - msg.addr = state->i2c_client->addr;
> - msg.flags = 0;
> - msg.len = 2;
> - for (i = 0; i < num; i++) {
> - msg.buf = (u8 *)[i];
> - ret = i2c_transfer(state->i2c_client->adapter, , 1);
> - if (ret == 0)
> - ret = -EIO;
> - if (ret < 0)
> - return ret;
> - }
> - return 0;
> -}
> -
> -static int reg_read(struct tc90522_state *state, u8 reg, u8 *val, u8 len)
> -{
> - struct i2c_msg msgs[2] = {
> - {
> - .addr = state->i2c_client->addr,
> - .flags = 0,
> - .buf = ,
> - .len = 1,
> - },
> - {
> - .addr = state->i2c_client->addr,
> - .flags = I2C_M_RD,
> - .buf = val,
> -   

Re: [RFC PATCH 3/4] media: Add refcount to keep track of media device registrations

[Mauro Carvalho Chehab]

Em Mon, 28 Mar 2016 15:37:43 -0600
Shuah Khan  escreveu:

> On 03/28/2016 12:28 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Mar 2016 22:38:44 -0600
> > Shuah Khan  escreveu:
> >   
> >> Add refcount to keep track of media device registrations to avoid release
> >> of media device when one of the drivers does unregister when media device
> >> belongs to more than one driver. Also add a new interfaces to unregister
> >> a media device allocated using Media Device Allocator and a hold register
> >> refcount. Change media_open() to get media device reference and put the
> >> reference in media_release().
> >>
> >> Signed-off-by: Shuah Khan 
> >> ---
> >>  drivers/media/media-device.c  | 53 
> >> +++
> >>  drivers/media/media-devnode.c |  3 +++
> >>  include/media/media-device.h  | 32 ++
> >>  3 files changed, 88 insertions(+)
> >>
> >> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> >> index 93aff4e..3359235 100644
> >> --- a/drivers/media/media-device.c
> >> +++ b/drivers/media/media-device.c
> >> @@ -36,6 +36,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  
> >>  #ifdef CONFIG_MEDIA_CONTROLLER
> >>  
> >> @@ -702,6 +703,7 @@ void media_device_init(struct media_device *mdev)
> >>INIT_LIST_HEAD(>entity_notify);
> >>mutex_init(>graph_mutex);
> >>ida_init(>entity_internal_idx);
> >> +  kref_init(>refcount);
> >>  
> >>dev_dbg(mdev->dev, "Media device initialized\n");
> >>  }
> >> @@ -730,6 +732,13 @@ printk("%s: mdev %p\n", __func__, mdev);
> >>/* Check if mdev was ever registered at all */
> >>mutex_lock(>graph_mutex);
> >>  
> >> +  /* if media device is already registered, bump the register refcount */
> >> +  if (media_devnode_is_registered(>devnode)) {
> >> +  kref_get(>refcount);
> >> +  mutex_unlock(>graph_mutex);
> >> +  return 0;
> >> +  }
> >> +
> >>/* Register the device node. */
> >>mdev->devnode.fops = _device_fops;
> >>mdev->devnode.parent = mdev->dev;
> >> @@ -756,6 +765,22 @@ err:
> >>  }
> >>  EXPORT_SYMBOL_GPL(__media_device_register);
> >>  
> >> +void media_device_register_ref(struct media_device *mdev)
> >> +{
> >> +  if (!mdev)
> >> +  return;
> >> +
> >> +  pr_info("%s: mdev %p\n", __func__, mdev);
> >> +  mutex_lock(>graph_mutex);
> >> +
> >> +  /* Check if mdev is registered - bump registered refcount */
> >> +  if (media_devnode_is_registered(>devnode))
> >> +  kref_get(>refcount);
> >> +
> >> +  mutex_unlock(>graph_mutex);
> >> +}
> >> +EXPORT_SYMBOL_GPL(media_device_register_ref);
> >> +
> >>  int __must_check media_device_register_entity_notify(struct media_device 
> >> *mdev,
> >>struct media_entity_notify *nptr)
> >>  {
> >> @@ -829,6 +854,34 @@ printk("%s: mdev=%p\n", __func__, mdev);
> >>  }
> >>  EXPORT_SYMBOL_GPL(media_device_unregister);
> >>  
> >> +static void __media_device_unregister_kref(struct kref *kref)
> >> +{
> >> +  struct media_device *mdev;
> >> +
> >> +  mdev = container_of(kref, struct media_device, refcount);
> >> +  __media_device_unregister(mdev);
> >> +}
> >> +
> >> +void media_device_unregister_put(struct media_device *mdev)
> >> +{
> >> +  int ret;
> >> +
> >> +  if (mdev == NULL)
> >> +  return;
> >> +
> >> +  pr_info("%s: mdev=%p\n", __func__, mdev);
> >> +  ret = kref_put_mutex(>refcount, __media_device_unregister_kref,
> >> +   >graph_mutex);
> >> +  if (ret) {
> >> +  /* __media_device_unregister() ran */
> >> +  __media_device_cleanup(mdev);
> >> +  mutex_unlock(>graph_mutex);
> >> +  mutex_destroy(>graph_mutex);
> >> +  media_device_set_to_delete_state(mdev->dev);  
> > 
> > Where you're freeing the media_dev (or its container struct)?
> > 
> > You need to be sure that it will be freed only here.  
> 
> This step doesn't free the media device. It simply move it from
> the main media device instance list to the to be deleted list.
> 
> This is necessary to handle race condition between ioctls and media
> device unregister. Consider the case where the driver does unregister
> while application has the device open and ioctl is in progress.

This can never happen, provided that the data is properly locked.

And if it is not locked, there will be other race issues.

> In this
> case, media device should not be released until the application exits
> with an error detecting media device has been unregistered. All ioctls
> check for this condition.
> 
> A second issue is if the media device isn't free'd, a subsequent driver
> bind finds the media device that is still in the list. So this flag is
> used to move the media device instance to a second to be deleted list.
> We do have to make sure the media device gets deleted from this to be
> deleted list in the cases when the applications 

Re: [RFC PATCH 1/4] media: Add Media Device Allocator API

[Mauro Carvalho Chehab]

Em Mon, 28 Mar 2016 15:34:15 -0600
Shuah Khan  escreveu:

> On 03/28/2016 12:28 PM, Mauro Carvalho Chehab wrote:
> > Hi Shuah,
> > 
> > I reviewed the entire patch series, but I'm adding the comments only here,
> > as the other patches are coherent with this one.  
> 
> That is fine.
> 
> > 
> > Em Fri, 25 Mar 2016 22:38:42 -0600
> > Shuah Khan  escreveu:
> >   
> >> Add Media Device Allocator API to manage Media Device life time problems.
> >> There are known problems with media device life time management. When media
> >> device is released while an media ioctl is in progress, ioctls fail with
> >> use-after-free errors and kernel hangs in some cases.
> >>
> >> Media Allocator API provides interfaces to allocate a refcounted media
> >> device from system wide global list and maintains the state until the
> >> last user of the media device releases it.
> >>
> >> Signed-off-by: Shuah Khan 
> >> ---
> >>  drivers/media/Makefile  |   3 +-
> >>  drivers/media/media-dev-allocator.c | 153 
> >> 
> >>  include/media/media-dev-allocator.h |  81 +++
> >>  3 files changed, 236 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/media/media-dev-allocator.c
> >>  create mode 100644 include/media/media-dev-allocator.h
> >>
> >> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> >> index e608bbc..b08f091 100644
> >> --- a/drivers/media/Makefile
> >> +++ b/drivers/media/Makefile
> >> @@ -2,7 +2,8 @@
> >>  # Makefile for the kernel multimedia device drivers.
> >>  #
> >>  
> >> -media-objs:= media-device.o media-devnode.o media-entity.o
> >> +media-objs:= media-device.o media-devnode.o media-entity.o \
> >> + media-dev-allocator.o
> >>  
> >>  #
> >>  # I2C drivers should come before other drivers, otherwise they'll fail
> >> diff --git a/drivers/media/media-dev-allocator.c 
> >> b/drivers/media/media-dev-allocator.c
> >> new file mode 100644
> >> index 000..51edc49
> >> --- /dev/null
> >> +++ b/drivers/media/media-dev-allocator.c
> >> @@ -0,0 +1,153 @@
> >> +/*
> >> + * media-devkref.c - Media Controller Device Allocator API
> >> + *
> >> + * Copyright (c) 2016 Shuah Khan 
> >> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> >> + *
> >> + * This file is released under the GPLv2.
> >> + * Credits: Suggested by Laurent Pinchart 
> >> 
> >> + */
> >> +
> >> +/*
> >> + * This file adds Media Controller Device Instance with
> >> + * Kref support. A system wide global media device list
> >> + * is managed and each  media device is refcounted. The
> >> + * last put on the media device releases the media device
> >> + * instance.
> >> +*/
> >> +
> >> +#ifdef CONFIG_MEDIA_CONTROLLER  
> > 
> > No need for an ifdef here. This file will be compiled only
> > if CONFIG_MEDIA_CONTROLLER, as you added it for media.ko
> > dependencies at the Makefile.  
> 
> Right. I will remove it.
> 
> >   
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +static LIST_HEAD(media_device_list);
> >> +static LIST_HEAD(media_device_to_delete_list);
> >> +static DEFINE_MUTEX(media_device_lock);
> >> +
> >> +struct media_device_instance {
> >> +  struct media_device mdev;
> >> +  struct list_head list;
> >> +  struct list_head to_delete_list;
> >> +  struct device *dev;
> >> +  struct kref refcount;  
> >   
> >> +  bool to_delete; /* should be set when devnode is deleted */  
> > 
> > I don't think this is needed.  
> 
> This is necessary to handle race condition between ioctls and media
> device unregister. Consider the case where the driver does unregister
> while application has the device open and ioctl is in progress. 

That is easy to handle: just take the graph_lock at the ioctl code
and at the unregister code. This will serialize unregistering.

> In this
> case, media device should not be released until the application exits
> with an error detecting media device has been unregistered. All ioctls
> check for this condition.
> 
> A second issue is if the media device isn't free'd, a subsequent driver
> bind finds the media device that is still in the list.

Again, you don't need a newer flag, as there's already one flag at
media_devnode that it is used for such case.

For media_device, this can be safely freed if properly locked, even
if media_devnode is not freed.

A new flag here just makes things more complicated, non-standard and
may lead into errors.

> So this flag is
> used to move the media device instance to a second to be deleted list.
> We do have to make sure the media device gets deleted from this to be
> deleted list in the cases when the applications dies without releasing
> the reference to the media device which triggers the put.
> 
> When more than one driver is in play (e.g: au0828 and snd_usb_audio),
> it is necessary to keep track of how many drivers 

[media 0/5] DVB driver for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards & PX-BCUD ISDB-S USB dongle

[info]

From: Буди Романто, AreMa Inc 

DVB driver for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards & PX-BCUD ISDB-S 
USB dongle
==

Status: stable

Features:
1. in addition to the real frequency:
ISDB-S : freq. channel ID
ISDB-T : freq# (I/O# +128), ch#, ch# +64 for CATV
2. in addition to TSID:
ISDB-S : slot#

Supported Cards & Main components:
A. EarthSoft PT3:
1. Altera   EP4CGX15BF14C8N : customized FPGA PCI bridge
2. Toshiba  TC90522XBG  : quad demodulator (2ch OFDM + 2ch 8PSK)
3. SharpVA4M6JC2103 : contains 2 ISDB-S + 2 ISDB-T tuners
ISDB-S : Sharp QM1D1C0042 RF-IC, chip ver. 0x48
ISDB-T : MaxLinear CMOS Hybrid TV MxL301RF

B. PLEX PX-Q3PE:
1. ASICEN   ASV5220 : PCI-E bridge
2. Toshiba  TC90522XBG  : quad demodulator (2ch OFDM + 2ch 8PSK)
3. NXP Semiconductors TDA20142  : ISDB-S tuner
4. Newport Media NM120  : ISDB-T tuner
5. ASICEN   ASIE5606X8  : crypting controller

C. PLEX PX-BCUD (ISDB-S USB dongle)
1. EmpiaEM28178 : USB I/F (courtesy of Nagahama Satoshi)
2. Toshiba  TC90532 : demodulator (using TC90522 driver)
3. SharpQM1D1C0045_2: ISDB-S RF-IC, chip ver. 0x68

Notes:
This is a complex but smartly polished driver package containing 2 (dual head)
PCI-E bridge I/F drivers, single demodulator frontend, and 4 (quad tail) tuner 
drivers,
plus, simplified Nagahama's patch for PLEX PX-BCUD (ISDB-S USB dongle).
Generic registration related procedures (subdevices, frontend, etc.) summarized 
in
ptx_common.c are very useful also for other DVB drivers, and would be very 
handy if
inserted into the core (e.g. dvb_frontend.c & dvb_frontend.h).

For example, currently, the entity of struct dvb_frontend is created sometimes 
in
demodulators, some in tuners, or even in the parent (bridge) drivers. IMHO, 
this entity
should be provided by dvb_core. ptx_register_fe() included in ptx_common.c 
simplifies
the tasks and in fact, significantly reduces coding & kernel size.

Also, currently dvb_frontend's .demodulator_priv & .tuner_priv are of type 
(void *).
These should be changed to (struct i2c_client *), IMHO. Private data for 
demodulator
or tuner should be attached under i2c_client, using i2c_set_clientdata() for 
instance.

FILENAMESUPPORTED CHIPS
===
tc90522.c   TC90522XBG, TC90532XBG,...
tda2014x.c  TDA20142
qm1d1c004x.cQM1D1C0042, QM1D1C0045, QM1D1C0045_2
nm131.c NM131, NM130, NM120
mxl301rf.c  MxL301RF
pt3_pci.c   EP4CGX15BF14C8N
pxq3pe_pci.cASV5220

Full package:
- URL:  https://github.com/knight-rider/ptx


Буди Романто, AreMa Inc (5):
  Raise adapter number limit
  drop backstabbing drivers
  Demodulator for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards &
PX-BCUD ISDB-S USB dongle
  Tuners for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards & PX-BCUD
ISDB-S USB dongle
  Bridge driver for PT3, PX-Q3PE & PX-BCUD

 drivers/media/Kconfig   |   5 +-
 drivers/media/dvb-core/Kconfig  |   4 +-
 drivers/media/dvb-core/dvbdev.h |   2 +-
 drivers/media/dvb-frontends/tc90522.c   | 964 +++-
 drivers/media/dvb-frontends/tc90522.h   |  36 +-
 drivers/media/pci/Kconfig   |   2 +-
 drivers/media/pci/Makefile  |   2 +-
 drivers/media/pci/pt3/Kconfig   |  10 -
 drivers/media/pci/pt3/Makefile  |   8 -
 drivers/media/pci/pt3/pt3.c | 874 -
 drivers/media/pci/pt3/pt3.h | 186 --
 drivers/media/pci/pt3/pt3_dma.c | 225 
 drivers/media/pci/pt3/pt3_i2c.c | 240 
 drivers/media/pci/ptx/Kconfig   |  23 +
 drivers/media/pci/ptx/Makefile  |   6 +
 drivers/media/pci/ptx/pt3.c | 426 ++
 drivers/media/pci/ptx/ptx_common.c  | 266 +
 drivers/media/pci/ptx/ptx_common.h  |  76 +++
 drivers/media/pci/ptx/pxq3pe.c  | 588 +++
 drivers/media/tuners/Kconfig|  21 +-
 drivers/media/tuners/Makefile   |   4 +-
 drivers/media/tuners/mxl301rf.c | 481 ++--
 drivers/media/tuners/mxl301rf.h |  19 +-
 drivers/media/tuners/nm131.c| 252 +
 drivers/media/tuners/nm131.h|  13 +
 drivers/media/tuners/qm1d1c0042.c   | 448 ---
 drivers/media/tuners/qm1d1c0042.h   |  37 --
 drivers/media/tuners/qm1d1c004x.c   | 247 
 drivers/media/tuners/qm1d1c004x.h   |  23 +
 drivers/media/tuners/tda2014x.c | 358 
 drivers/media/tuners/tda2014x.h |  13 +
 drivers/media/usb/em28xx/Kconfig|   3 +
 drivers/media/usb/em28xx/Makefile   |   1 +
 drivers/media/usb/em28xx/em28xx-cards.c |  27 +
 drivers/media/usb/em28xx/em28xx-dvb.c   |  81 ++-
 

[media 1/5] Raise adapter number limit

[info]

From: Буди Романто, AreMa Inc 

The current limit is too low for latest cards with 8+ tuners on a single slot.
IMHO, the most appropriate minimum default is 16.

Signed-off-by: Буди Романто, AreMa Inc 
---
 drivers/media/dvb-core/Kconfig  | 4 ++--
 drivers/media/dvb-core/dvbdev.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-core/Kconfig b/drivers/media/dvb-core/Kconfig
index fa7a249..91732a9 100644
--- a/drivers/media/dvb-core/Kconfig
+++ b/drivers/media/dvb-core/Kconfig
@@ -5,7 +5,7 @@
 config DVB_MAX_ADAPTERS
int "maximum number of DVB/ATSC adapters"
depends on DVB_CORE
-   default 8
+   default 16
range 1 255
help
  Maximum number of DVB/ATSC adapters. Increasing this number
@@ -13,7 +13,7 @@ config DVB_MAX_ADAPTERS
  if a much lower number of DVB/ATSC adapters is present.
  Only values in the range 4-32 are tested.
 
- If you are unsure about this, use the default value 8
+ If you are unsure about this, use the default value 16
 
 config DVB_DYNAMIC_MINORS
bool "Dynamic DVB minor allocation"
diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
index 4aff7bd..ae4e0a2 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -34,7 +34,7 @@
 #if defined(CONFIG_DVB_MAX_ADAPTERS) && CONFIG_DVB_MAX_ADAPTERS > 0
   #define DVB_MAX_ADAPTERS CONFIG_DVB_MAX_ADAPTERS
 #else
-  #define DVB_MAX_ADAPTERS 8
+  #define DVB_MAX_ADAPTERS 16
 #endif
 
 #define DVB_UNSET (-1)
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[media 4/5] Tuners for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards & PX-BCUD ISDB-S USB dongle

[info]

From: Буди Романто, AreMa Inc 

tda2014x.c  TDA20142PX-Q3PE
qm1d1c004x.cQM1D1C0042, QM1D1C0045, QM1D1C0045_2PX-BCUD, PT3
nm131.c NM131, NM130, NM120 PX-Q3PE
mxl301rf.c  MxL301RFPT3

Signed-off-by: Буди Романто, AreMa Inc 
---
 drivers/media/tuners/Kconfig  |  21 ++-
 drivers/media/tuners/Makefile |   4 +-
 drivers/media/tuners/mxl301rf.c   | 230 
 drivers/media/tuners/mxl301rf.h   |  23 +++
 drivers/media/tuners/nm131.c  | 252 +++
 drivers/media/tuners/nm131.h  |  13 ++
 drivers/media/tuners/qm1d1c004x.c | 247 ++
 drivers/media/tuners/qm1d1c004x.h |  23 +++
 drivers/media/tuners/tda2014x.c   | 358 ++
 drivers/media/tuners/tda2014x.h   |  13 ++
 10 files changed, 1180 insertions(+), 4 deletions(-)
 create mode 100644 drivers/media/tuners/mxl301rf.c
 create mode 100644 drivers/media/tuners/mxl301rf.h
 create mode 100644 drivers/media/tuners/nm131.c
 create mode 100644 drivers/media/tuners/nm131.h
 create mode 100644 drivers/media/tuners/qm1d1c004x.c
 create mode 100644 drivers/media/tuners/qm1d1c004x.h
 create mode 100644 drivers/media/tuners/tda2014x.c
 create mode 100644 drivers/media/tuners/tda2014x.h

diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index 05998f0..a7f044b 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -271,10 +271,25 @@ config MEDIA_TUNER_MXL301RF
help
  MaxLinear MxL301RF OFDM tuner driver.
 
-config MEDIA_TUNER_QM1D1C0042
-   tristate "Sharp QM1D1C0042 tuner"
+config MEDIA_TUNER_QM1D1C004X
+   tristate "Sharp QM1D1C004x tuner"
depends on MEDIA_SUPPORT && I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
help
- Sharp QM1D1C0042 trellis coded 8PSK tuner driver.
+ Sharp trellis coded 8PSK tuner driver.
+ Supported chips: QM1D1C0042, QM1D1C0045
+
+config MEDIA_TUNER_NM131
+   tristate "Newport Media tuners NM131, NM130 and NM120"
+   depends on MEDIA_SUPPORT && I2C
+   default m if !MEDIA_SUBDRV_AUTOSELECT
+   help
+ Newport Media NM131, NM130 and NM120 tuner driver.
+
+config MEDIA_TUNER_TDA2014X
+   tristate "NXP Semiconductors TDA2014x tuner"
+   depends on MEDIA_SUPPORT && I2C
+   default m if !MEDIA_SUBDRV_AUTOSELECT
+   help
+ NXP Semiconductor TDA2014x tuner driver.
 endmenu
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index 06a9ab6..6a2b52a 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -39,8 +39,10 @@ obj-$(CONFIG_MEDIA_TUNER_FC0013) += fc0013.o
 obj-$(CONFIG_MEDIA_TUNER_IT913X) += it913x.o
 obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
 obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
-obj-$(CONFIG_MEDIA_TUNER_QM1D1C0042) += qm1d1c0042.o
+obj-$(CONFIG_MEDIA_TUNER_QM1D1C004X) += qm1d1c004x.o
 obj-$(CONFIG_MEDIA_TUNER_M88RS6000T) += m88rs6000t.o
+obj-$(CONFIG_MEDIA_TUNER_NM131) += nm131.o
+obj-$(CONFIG_MEDIA_TUNER_TDA2014X) += tda2014x.o
 
 ccflags-y += -I$(srctree)/drivers/media/dvb-core
 ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/tuners/mxl301rf.c b/drivers/media/tuners/mxl301rf.c
new file mode 100644
index 000..6d5f4f0
--- /dev/null
+++ b/drivers/media/tuners/mxl301rf.c
@@ -0,0 +1,230 @@
+/*
+   Sharp VA4M6JC2103 - Earthsoft PT3 ISDB-T tuner MaxLinear CMOS Hybrid TV 
MxL301RF
+
+   Copyright (C) Budi Rachmanto, AreMa Inc. 
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+*/
+
+#include "dvb_frontend.h"
+#include "mxl301rf.h"
+
+int mxl301rf_w(struct dvb_frontend *fe, u8 slvadr, const u8 *dat, int len)
+{
+   struct i2c_client   *d  = fe->demodulator_priv;
+   u8  *buf= kzalloc(len + 1, GFP_KERNEL);
+   int ret;
+   struct i2c_msg  msg[] = {
+   {.addr = d->addr,   .flags = 0, .buf = buf, .len = 
len + 1,},
+   };
+
+   if (!buf)
+   return -ENOMEM;
+   buf[0]  = slvadr;
+   memcpy(buf + 1, dat, len);
+   ret = i2c_transfer(d->adapter, msg, 1);
+   kfree(buf);
+   return  ret == 1 ? 0 : -EIO;
+}
+
+int mxl301rf_w_tuner(struct dvb_frontend *fe, const u8 *dat, int len)
+{
+   u8  *buf= kzalloc(len + 1, GFP_KERNEL);
+   int ret;
+
+   if (!buf)
+   return -ENOMEM;
+   buf[0]  = ((struct i2c_client *)fe->tuner_priv)->addr << 1;
+   memcpy(buf + 1, dat, len);
+   ret = mxl301rf_w(fe, 0xFE, buf, len + 1);
+   

[media 2/5] drop backstabbing drivers

[info]

From: Буди Романто, AreMa Inc 

Obsoleted & superseded, please read cover letter for details.

Signed-off-by: Буди Романто, AreMa Inc 
---
 drivers/media/dvb-frontends/tc90522.c | 840 
 drivers/media/dvb-frontends/tc90522.h |  42 --
 drivers/media/pci/pt3/Kconfig |  10 -
 drivers/media/pci/pt3/Makefile|   8 -
 drivers/media/pci/pt3/pt3.c   | 874 --
 drivers/media/pci/pt3/pt3.h   | 186 
 drivers/media/pci/pt3/pt3_dma.c   | 225 -
 drivers/media/pci/pt3/pt3_i2c.c   | 240 --
 drivers/media/tuners/mxl301rf.c   | 349 --
 drivers/media/tuners/mxl301rf.h   |  26 -
 drivers/media/tuners/qm1d1c0042.c | 448 -
 drivers/media/tuners/qm1d1c0042.h |  37 --
 12 files changed, 3285 deletions(-)
 delete mode 100644 drivers/media/dvb-frontends/tc90522.c
 delete mode 100644 drivers/media/dvb-frontends/tc90522.h
 delete mode 100644 drivers/media/pci/pt3/Kconfig
 delete mode 100644 drivers/media/pci/pt3/Makefile
 delete mode 100644 drivers/media/pci/pt3/pt3.c
 delete mode 100644 drivers/media/pci/pt3/pt3.h
 delete mode 100644 drivers/media/pci/pt3/pt3_dma.c
 delete mode 100644 drivers/media/pci/pt3/pt3_i2c.c
 delete mode 100644 drivers/media/tuners/mxl301rf.c
 delete mode 100644 drivers/media/tuners/mxl301rf.h
 delete mode 100644 drivers/media/tuners/qm1d1c0042.c
 delete mode 100644 drivers/media/tuners/qm1d1c0042.h

diff --git a/drivers/media/dvb-frontends/tc90522.c 
b/drivers/media/dvb-frontends/tc90522.c
deleted file mode 100644
index 31cd325..000
--- a/drivers/media/dvb-frontends/tc90522.c
+++ /dev/null
@@ -1,840 +0,0 @@
-/*
- * Toshiba TC90522 Demodulator
- *
- * Copyright (C) 2014 Akihiro Tsukada 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2.
- *
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-/*
- * NOTICE:
- * This driver is incomplete and lacks init/config of the chips,
- * as the necessary info is not disclosed.
- * It assumes that users of this driver (such as a PCI bridge of
- * DTV receiver cards) properly init and configure the chip
- * via I2C *before* calling this driver's init() function.
- *
- * Currently, PT3 driver is the only one that uses this driver,
- * and contains init/config code in its firmware.
- * Thus some part of the code might be dependent on PT3 specific config.
- */
-
-#include 
-#include 
-#include 
-#include "dvb_math.h"
-#include "tc90522.h"
-
-#define TC90522_I2C_THRU_REG 0xfe
-
-#define TC90522_MODULE_IDX(addr) (((u8)(addr) & 0x02U) >> 1)
-
-struct tc90522_state {
-   struct tc90522_config cfg;
-   struct dvb_frontend fe;
-   struct i2c_client *i2c_client;
-   struct i2c_adapter tuner_i2c;
-
-   bool lna;
-};
-
-struct reg_val {
-   u8 reg;
-   u8 val;
-};
-
-static int
-reg_write(struct tc90522_state *state, const struct reg_val *regs, int num)
-{
-   int i, ret;
-   struct i2c_msg msg;
-
-   ret = 0;
-   msg.addr = state->i2c_client->addr;
-   msg.flags = 0;
-   msg.len = 2;
-   for (i = 0; i < num; i++) {
-   msg.buf = (u8 *)[i];
-   ret = i2c_transfer(state->i2c_client->adapter, , 1);
-   if (ret == 0)
-   ret = -EIO;
-   if (ret < 0)
-   return ret;
-   }
-   return 0;
-}
-
-static int reg_read(struct tc90522_state *state, u8 reg, u8 *val, u8 len)
-{
-   struct i2c_msg msgs[2] = {
-   {
-   .addr = state->i2c_client->addr,
-   .flags = 0,
-   .buf = ,
-   .len = 1,
-   },
-   {
-   .addr = state->i2c_client->addr,
-   .flags = I2C_M_RD,
-   .buf = val,
-   .len = len,
-   },
-   };
-   int ret;
-
-   ret = i2c_transfer(state->i2c_client->adapter, msgs, ARRAY_SIZE(msgs));
-   if (ret == ARRAY_SIZE(msgs))
-   ret = 0;
-   else if (ret >= 0)
-   ret = -EIO;
-   return ret;
-}
-
-static struct tc90522_state *cfg_to_state(struct tc90522_config *c)
-{
-   return container_of(c, struct tc90522_state, cfg);
-}
-
-
-static int tc90522s_set_tsid(struct dvb_frontend *fe)
-{
-   struct reg_val set_tsid[] = {
-   { 0x8f, 00 },
-   { 0x90, 00 }
-   };
-
-   set_tsid[0].val = (fe->dtv_property_cache.stream_id & 0xff00) >> 8;
-   set_tsid[1].val = 

[media 3/5] Demodulator for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards & PX-BCUD ISDB-S USB dongle

[info]

From: Буди Романто, AreMa Inc 

Toshiba TC905xx demodulator driver for PT3, PX-Q3PE & PX-BCUD

Signed-off-by: Буди Романто, AreMa Inc 
---
 drivers/media/dvb-frontends/tc90522.c | 254 ++
 drivers/media/dvb-frontends/tc90522.h |  18 +++
 2 files changed, 272 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/tc90522.c
 create mode 100644 drivers/media/dvb-frontends/tc90522.h

diff --git a/drivers/media/dvb-frontends/tc90522.c 
b/drivers/media/dvb-frontends/tc90522.c
new file mode 100644
index 000..c1c48e5
--- /dev/null
+++ b/drivers/media/dvb-frontends/tc90522.c
@@ -0,0 +1,254 @@
+/*
+   Toshiba TC90522XBG 2ch OFDM(ISDB-T) + 2ch 8PSK(ISDB-S) demodulator
+
+   Copyright (C) Budi Rachmanto, AreMa Inc. 
+
+   CHIPCARDS
+   TC90522XBG  Earthsoft PT3, PLEX PX-Q3PE
+   TC90532 PLEX PX-BCUD
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+ */
+
+#include "dvb_math.h"
+#include "dvb_frontend.h"
+#include "tc90522.h"
+
+bool tc90522_r(struct i2c_client *d, u8 slvadr, u8 *buf, u8 len)
+{
+   struct i2c_msg msg[] = {
+   {.addr = d->addr,   .flags = 0, .buf = , 
.len = 1,},
+   {.addr = d->addr,   .flags = I2C_M_RD,  .buf = buf, 
.len = len,},
+   };
+   return i2c_transfer(d->adapter, msg, 2) == 2;
+}
+
+bool tc90522_w(struct i2c_client *d, u8 slvadr, u8 dat)
+{
+   u8 buf[] = {slvadr, dat};
+   struct i2c_msg msg[] = {
+   {.addr = d->addr,   .flags = 0, .buf = buf, .len = 
2,},
+   };
+   return i2c_transfer(d->adapter, msg, 1) == 1;
+}
+
+u64 tc90522_n2int(const u8 *data, u8 n)/* convert n_bytes data 
from stream (network byte order) to integer */
+{  /* can't use 's 
ntoh*() as sometimes n = 3,5,...   */
+   u32 i, val = 0;
+
+   for (i = 0; i < n; i++) {
+   val <<= 8;
+   val |= data[i];
+   }
+   return val;
+}
+
+int tc90522_cn_raw(struct dvb_frontend *fe, u16 *raw)  /* for DVBv3 
compatibility  */
+{
+   u8  buf[3],
+   len = fe->dtv_property_cache.delivery_system == SYS_ISDBS ? 
2 : 3,
+   adr = fe->dtv_property_cache.delivery_system == SYS_ISDBS ? 
0xbc : 0x8b;
+   boolok  = tc90522_r(fe->demodulator_priv, adr, buf, len);
+   int cn  = tc90522_n2int(buf, len);
+
+   if (!ok)
+   return -EIO;
+   *raw = cn;
+   return cn;
+}
+
+int tc90522_status(struct dvb_frontend *fe, enum fe_status *stat)
+{
+   enum fe_status  *festat = 
i2c_get_clientdata(fe->demodulator_priv);
+   struct dtv_frontend_properties  *c  = >dtv_property_cache;
+   u16 v16;
+   s64 raw = tc90522_cn_raw(fe, ),
+   x,
+   y;
+
+   s64 cn_s(void)  /* @ .0001 dB */
+   {
+   raw -= 3000;
+   if (raw < 0)
+   raw = 0;
+   x = int_sqrt(raw << 20);
+   y = 16346ll * x - (143410ll << 16);
+   y = ((x * y) >> 16) + (502590ll << 16);
+   y = ((x * y) >> 16) - (889770ll << 16);
+   y = ((x * y) >> 16) + (895650ll << 16);
+   y = (588570ll << 16) - ((x * y) >> 16);
+   return y < 0 ? 0 : y >> 16;
+   }
+
+   s64 cn_t(void)  /* @ .0001 dB */
+   {
+   if (!raw)
+   return 0;
+   x = (1130911733ll - 10ll * intlog10(raw)) >> 2;
+   y = (x >> 2) - (x >> 6) + (x >> 8) + (x >> 9) - (x >> 10) + (x 
>> 11) + (x >> 12) - (16ll << 22);
+   y = ((x * y) >> 22) + (398ll << 22);
+   y = ((x * y) >> 22) + (5491ll << 22);
+   y = ((x * y) >> 22) + (30965ll << 22);
+   return y >> 22;
+   }
+
+   c->cnr.len  = 1;
+   c->cnr.stat[0].svalue   = fe->dtv_property_cache.delivery_system == 
SYS_ISDBS ? cn_s() : cn_t();
+   c->cnr.stat[0].scale= FE_SCALE_DECIBEL;
+   *stat = *festat;
+   return *festat;
+}
+
+int tc90522_get_frontend_algo(struct dvb_frontend *fe)
+{
+   return DVBFE_ALGO_HW;
+}
+
+int tc90522_tune(struct dvb_frontend *fe, bool retune, u32 mode_flags, u32 
*delay, enum fe_status *stat)
+{
+   u32 fno2kHz(u32 fno)
+   {
+   if (fno < 12)
+   return 1049480 + 38360 * fno;   /* BS   
*/
+   else if (fno < 24)
+   return 1613000 + 4 * (fno - 12);/* CS110 right  
*/
+   return 1593000 + 4 * (fno - 24);/* CS110 left   
*/
+   

[media 5/5] Bridge driver for PT3, PX-Q3PE & PX-BCUD

[info]

From: Буди Романто, AreMa Inc 

Bridge driver for Earthsoft PT3, PLEX PX-Q3PE ISDB-S/T PCIE cards & PX-BCUD 
ISDB-S USB dongle.
Including simplified Nagahama's patch for PLEX PX-BCUD (ISDB-S usb dongle)...
Please read cover letter for details.

Signed-off-by: Буди Романто, AreMa Inc 
---
 drivers/media/Kconfig   |   5 +-
 drivers/media/pci/Kconfig   |   2 +-
 drivers/media/pci/Makefile  |   2 +-
 drivers/media/pci/ptx/Kconfig   |  23 ++
 drivers/media/pci/ptx/Makefile  |   6 +
 drivers/media/pci/ptx/pt3.c | 426 +++
 drivers/media/pci/ptx/ptx_common.c  | 266 +++
 drivers/media/pci/ptx/ptx_common.h  |  76 +
 drivers/media/pci/ptx/pxq3pe.c  | 588 
 drivers/media/usb/em28xx/Kconfig|   3 +
 drivers/media/usb/em28xx/Makefile   |   1 +
 drivers/media/usb/em28xx/em28xx-cards.c |  27 ++
 drivers/media/usb/em28xx/em28xx-dvb.c   |  81 -
 drivers/media/usb/em28xx/em28xx.h   |   1 +
 14 files changed, 1502 insertions(+), 5 deletions(-)
 create mode 100644 drivers/media/pci/ptx/Kconfig
 create mode 100644 drivers/media/pci/ptx/Makefile
 create mode 100644 drivers/media/pci/ptx/pt3.c
 create mode 100644 drivers/media/pci/ptx/ptx_common.c
 create mode 100644 drivers/media/pci/ptx/ptx_common.h
 create mode 100644 drivers/media/pci/ptx/pxq3pe.c

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index a8518fb..37fae59 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -149,7 +149,10 @@ config DVB_NET
  You may want to disable the network support on embedded devices. If
  unsure say Y.
 
-# This Kconfig option is used by both PCI and USB drivers
+# Options used by both PCI and USB drivers
+config DVB_PTX_COMMON
+   tristate
+
 config TTPCI_EEPROM
tristate
depends on I2C
diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
index 48a611b..9d63ad6 100644
--- a/drivers/media/pci/Kconfig
+++ b/drivers/media/pci/Kconfig
@@ -44,7 +44,7 @@ source "drivers/media/pci/b2c2/Kconfig"
 source "drivers/media/pci/pluto2/Kconfig"
 source "drivers/media/pci/dm1105/Kconfig"
 source "drivers/media/pci/pt1/Kconfig"
-source "drivers/media/pci/pt3/Kconfig"
+source "drivers/media/pci/ptx/Kconfig"
 source "drivers/media/pci/mantis/Kconfig"
 source "drivers/media/pci/ngene/Kconfig"
 source "drivers/media/pci/ddbridge/Kconfig"
diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
index 5f8aacb..984e37c 100644
--- a/drivers/media/pci/Makefile
+++ b/drivers/media/pci/Makefile
@@ -7,7 +7,7 @@ obj-y+= ttpci/  \
pluto2/ \
dm1105/ \
pt1/\
-   pt3/\
+   ptx/\
mantis/ \
ngene/  \
ddbridge/   \
diff --git a/drivers/media/pci/ptx/Kconfig b/drivers/media/pci/ptx/Kconfig
new file mode 100644
index 000..53ec5ea
--- /dev/null
+++ b/drivers/media/pci/ptx/Kconfig
@@ -0,0 +1,23 @@
+config DVB_PT3
+   tristate "Earthsoft PT3 cards"
+   depends on DVB_CORE && PCI && I2C
+   select DVB_PTX_COMMON
+   select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_QM1D1C004X if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_MXL301RF if MEDIA_SUBDRV_AUTOSELECT
+   help
+ Support for Earthsoft PT3 ISDB-S/T PCIe cards.
+
+ Say Y or M if you own such a device and want to use it.
+
+config DVB_PXQ3PE
+   tristate "PLEX PX-Q3PE cards"
+   depends on DVB_CORE && PCI && I2C
+   select DVB_PTX_COMMON
+   select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_QM1D1C004X if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_MXL301RF if MEDIA_SUBDRV_AUTOSELECT
+   help
+ Support for PLEX PX-Q3PE ISDB-S/T PCIe cards.
+
+ Say Y or M if you own such a device and want to use it.
diff --git a/drivers/media/pci/ptx/Makefile b/drivers/media/pci/ptx/Makefile
new file mode 100644
index 000..9c41328
--- /dev/null
+++ b/drivers/media/pci/ptx/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_DVB_PTX_COMMON)   += ptx_common.o
+obj-$(CONFIG_DVB_PT3)  += pt3.o
+obj-$(CONFIG_DVB_PXQ3PE)   += pxq3pe.o
+
+ccflags-y += -Idrivers/media/dvb-core -Idrivers/media/dvb-frontends 
-Idrivers/media/tuners
+
diff --git a/drivers/media/pci/ptx/pt3.c b/drivers/media/pci/ptx/pt3.c
new file mode 100644
index 000..0f67751
--- /dev/null
+++ b/drivers/media/pci/ptx/pt3.c
@@ -0,0 +1,426 @@
+/*
+   DVB driver for Earthsoft PT3 ISDB-S/T PCIE bridge Altera Cyclone IV 
FPGA EP4CGX15BF14C8N
+
+   Copyright (C) Budi Rachmanto, AreMa Inc. 
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   

Re: [PATCH] si2168: use i2c controlled mux interface

[Peter Rosin]

On 2016-04-05 16:50, Antti Palosaari wrote:
> On 03/23/2016 06:58 PM, Peter Rosin wrote:
>> On 2016-01-06 06:42, Antti Palosaari wrote:
>>> Recent i2c mux locking update offers support for i2c controlled i2c
>>> muxes. Use it and get the rid of homemade hackish i2c adapter
>>> locking code.
>>
>> [actual patch elided]
>>
>> I had a 2nd look and it seems that the saa7164 driver has support for
>> a HVR2055 card with dual si2168 chips. These two chips appear to sit
>> on the same i2c-bus with different i2c-addresses (0x64 and 0x66) and
>> with gates (implemented as muxes) to two identical tuners with the
>> same i2c-address (0x60). Do I read it right?
> 
> saa7164 has 3 different I2C adapters.
> 
> saa7164 I2C bus #0:
> * eeprom
> * Si2157 #1
> 
> saa7164 I2C bus #1:
> * Si2157 #2
> 
> saa7164 I2C bus #2:
> * Si2168 #1
> * Si2168 #2
> 
> So both of the Si2157 tuners could have same addresses.
> 
> (It is Hauppauge WinTV-HVR2205, not HVR-2055).

Ok, so I did read it right.

>> With the current i2c-mux-locking (parent-locked muxes), this works
>> fine as an access to one of the tuners locks the root i2c adapter
>> and thus the other tuner is also locked out. But with the upcoming
>> i2c-mux-locking for i2c-controlled muxes (self-locked muxes), the
>> root i2c adapter would no longer be locked for the full transaction
>> when one of the tuners is accessed. This means that accesses to the
>> two tuners may interleave and cause all kinds of trouble, should
>> both gates be open at the same time. So, is it really correct and
>> safe to change the si2168 driver to use a self-locked mux?
>>
>> Unless there is some other mechanism that prevents the two tuners
>> from being accessed in parallel, I think not. But maybe there is such
>> a mechanism?
> 
> Good point. Actually there is pretty often this kind of configuration used 
> for those dual tuner devices and it will cause problems... Currently all of 
> those implements hackish i2c_gate_ctrl() callback to switch mux.
> 
>        
> |I2C-adapter | |  I2C-mux   | | I2C-client |
> || || ||
> || | addr 0x1c  | | addr 0x60  |
> || || ||
> ||-+-I2C---|-/ -|---I2C---||
> || |   || ||
>|   
>|   |  I2C-mux   | | I2C-client |
>|   || ||
>|   | addr 0x1d  | | addr 0x60  |
>|   || ||
>+-I2C---|-/ -|---I2C---||
>|| ||

Right, so self-locked muxes (as in v5 [1]) can't do the job,
but mux-locked muxes (as in v6 [2]) should be fine. The v6 mux-
locked muxes grab a new mux_lock in the parent adapter where
the v5 self-locked muxes grabbed a lock in the mux itself. Which
means that sibling muxes will lock each other out with v6 when
they go for the same lock, which is what we want.

Cheers,
Peter

(v5 and v6 refer to the mux locking update patch series)

[1] http://marc.info/?l=linux-i2c=145805103325611=2
[2] http://marc.info/?l=linux-i2c=145967417924732=2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] si2168: use i2c controlled mux interface

[Antti Palosaari]

On 03/23/2016 06:58 PM, Peter Rosin wrote:

On 2016-01-06 06:42, Antti Palosaari wrote:

Recent i2c mux locking update offers support for i2c controlled i2c
muxes. Use it and get the rid of homemade hackish i2c adapter
locking code.


[actual patch elided]

I had a 2nd look and it seems that the saa7164 driver has support for
a HVR2055 card with dual si2168 chips. These two chips appear to sit
on the same i2c-bus with different i2c-addresses (0x64 and 0x66) and
with gates (implemented as muxes) to two identical tuners with the
same i2c-address (0x60). Do I read it right?


saa7164 has 3 different I2C adapters.

saa7164 I2C bus #0:
* eeprom
* Si2157 #1

saa7164 I2C bus #1:
* Si2157 #2

saa7164 I2C bus #2:
* Si2168 #1
* Si2168 #2

So both of the Si2157 tuners could have same addresses.

(It is Hauppauge WinTV-HVR2205, not HVR-2055).


With the current i2c-mux-locking (parent-locked muxes), this works
fine as an access to one of the tuners locks the root i2c adapter
and thus the other tuner is also locked out. But with the upcoming
i2c-mux-locking for i2c-controlled muxes (self-locked muxes), the
root i2c adapter would no longer be locked for the full transaction
when one of the tuners is accessed. This means that accesses to the
two tuners may interleave and cause all kinds of trouble, should
both gates be open at the same time. So, is it really correct and
safe to change the si2168 driver to use a self-locked mux?

Unless there is some other mechanism that prevents the two tuners
from being accessed in parallel, I think not. But maybe there is such
a mechanism?


Good point. Actually there is pretty often this kind of configuration 
used for those dual tuner devices and it will cause problems... 
Currently all of those implements hackish i2c_gate_ctrl() callback to 
switch mux.


       
|I2C-adapter | |  I2C-mux   | | I2C-client |
|| || ||
|| | addr 0x1c  | | addr 0x60  |
|| || ||
||-+-I2C---|-/ -|---I2C---||
|| |   || ||
   |   
   |   |  I2C-mux   | | I2C-client |
   |   || ||
   |   | addr 0x1d  | | addr 0x60  |
   |   || ||
   +-I2C---|-/ -|---I2C---||
   || ||


regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 0/5] Media Device Allocator API

[Shuah Khan]

On 04/05/2016 12:10 AM, Takashi Iwai wrote:
> On Tue, 05 Apr 2016 05:35:55 +0200,
> Shuah Khan wrote:
>>
>> There are known problems with media device life time management. When media
>> device is released while an media ioctl is in progress, ioctls fail with
>> use-after-free errors and kernel hangs in some cases.
>>
>> Media Device can be in any the following states:
>>
>> - Allocated
>> - Registered (could be tied to more than one driver)
>> - Unregistered, not in use (media device file is not open)
>> - Unregistered, in use (media device file is not open)
>> - Released
>>
>> When media device belongs to  more than one driver, registrations should be
>> tracked to avoid unregistering when one of the drivers does unregister. A new
>> num_drivers field in the struct media_device covers this case. The media 
>> device
>> should be unregistered only when the last unregister occurs with num_drivers
>> count zero.
>>
>> When a media device is in use when it is unregistered, it should not be
>> released until the application exits when it detects the unregistered
>> status. Media device that is in use when it is unregistered is moved to
>> to_delete_list. When the last unregister occurs, media device is unregistered
>> and becomes an unregistered, still allocated device. Unregister marks the
>> device to be deleted.
>>
>> When media device belongs to more than one driver, as both drivers could be
>> unbound/bound, driver should not end up getting stale media device that is
>> on its way out. Moving the unregistered media device to to_delete_list helps
>> this case as well.
>>
>> I ran bind/unbind loop tests on uvcvideo, au0828, and snd-usb-audio while
>> running application that does ioctls. Didn't see any use-after-free errors
>> on media device. A couple of known issues seen:
>>
>> 1. When application exits, cdev_put() gets called after media device is
>>released. This is a known issue to resolve and Media Device Allocator
>>can't solve this one.
>> 2. When au0828 module is removed and then ioctls fail when cdev_get() looks
>>for the owning module as au0828 is very often the module that owns the
>>media devnode. This is a cdev related issue that needs to be resolved and
>>Media Device Allocator can't solve this one.
>>
>> Shuah Khan (5):
>>   media: Add Media Device Allocator API
>>   media: Add driver count to keep track of media device registrations
>>   media: uvcvideo change to use Media Device Allocator API
>>   media: au0828 change to use Media Device Allocator API
>>   sound/usb: Use Media Controller API to share media resources
> 
> I don't think we need to include usb-audio patch at this stage yet.
> The most important thing for now is to improve / stabilize the API
> itself so that other drivers can use it as is.  Once when the API is
> really stabilized, we create a solid git branch that may be based for
> multiple subsystems, and I'll merge usb-audio stuff through sound git
> tree.

Agreed. I included snd-usb-audio as it provides a good test case for
multiple driver use-case. Yes it is a good idea to have a git branch
for wider testing.

> 
> Also, the previous usb-audio MC implementation had a few serious bugs,
> including quirk NULL dereference.  See the bugzilla below for some fix
> patches to 4.6-rc1:
>   https://bugzilla.kernel.org/show_bug.cgi?id=115561
> Feel free to fold them in, if they are still valid.

I folded them in. It is unfortunate that these bugs were introduced towards
the end when I was making changes to address review comments and I didn't
catch them, especially the quirk NULL dereference.

thanks,
-- Shuah

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 19/24] i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes

[Peter Rosin]

On 2016-04-03 13:09, Jonathan Cameron wrote:
> On 03/04/16 09:52, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Signed-off-by: Peter Rosin 
> Very nice, one typo that I could see.

Thanks!

*snip*

>> + and the actual transfer (e.g. if the child mux is auto-closing
>> + and the parent mux issus i2c-transfers as part of its select).
>> + This is especailly the case if the parent mux is mux-locked, but
> especially

Fixed now in my local repo.

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 14/24] of/unittest: convert to use an explicit i2c mux core

[Peter Rosin]

On 2016-04-04 07:16, Rob Herring wrote:
> On Sun, Apr 03, 2016 at 10:52:44AM +0200, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Allocate an explicit i2c mux core to handle parent and child adapters
>> etc. Update the select op to be in terms of the i2c mux core instead
>> of the child adapter.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/of/unittest.c | 40 +++-
>>  1 file changed, 15 insertions(+), 25 deletions(-)
> 
> I assume you ran the unittest...

It's one of the few drivers I do have hardware for, so yes, I did
indeed test it!

> Acked-by: Rob Herring 

Thanks!

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/7] scatterlist: add sg_alloc_table_from_buf() helper

[Dave Gordon]

On 30/03/16 19:18, Boris Brezillon wrote:

On Wed, 30 Mar 2016 09:51:43 -0700
Mark Brown  wrote:


On Wed, Mar 30, 2016 at 05:39:51PM +0200, Boris Brezillon wrote:

sg_alloc_table_from_buf() provides an easy solution to create an sg_table
from a virtual address pointer. This function takes care of dealing with
vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
DMA transfer size).


This seems nice.  Should we also have a further helper on top of this
which will get constraints from a dmaengine, it seems like it'd be a
common need?


Yep, we could create a wrapper extracting dma_slave caps info,
converting it to sg_constraints and calling sg_alloc_table_from_buf().
But let's try to get this function accepted first, and I'll send another
patch providing this wrapper.

BTW, do you see other things that should be added in sg_constraints?



You could compare with the things Solaris uses to describe the 
restrictions on a DMA binding ...


http://docs.oracle.com/cd/E23824_01/html/821-1478/ddi-dma-attr-9s.html#REFMAN9Sddi-dma-attr-9s

.Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 0/5] Media Device Allocator API

[Takashi Iwai]

On Tue, 05 Apr 2016 05:35:55 +0200,
Shuah Khan wrote:
> 
> There are known problems with media device life time management. When media
> device is released while an media ioctl is in progress, ioctls fail with
> use-after-free errors and kernel hangs in some cases.
> 
> Media Device can be in any the following states:
> 
> - Allocated
> - Registered (could be tied to more than one driver)
> - Unregistered, not in use (media device file is not open)
> - Unregistered, in use (media device file is not open)
> - Released
> 
> When media device belongs to  more than one driver, registrations should be
> tracked to avoid unregistering when one of the drivers does unregister. A new
> num_drivers field in the struct media_device covers this case. The media 
> device
> should be unregistered only when the last unregister occurs with num_drivers
> count zero.
> 
> When a media device is in use when it is unregistered, it should not be
> released until the application exits when it detects the unregistered
> status. Media device that is in use when it is unregistered is moved to
> to_delete_list. When the last unregister occurs, media device is unregistered
> and becomes an unregistered, still allocated device. Unregister marks the
> device to be deleted.
> 
> When media device belongs to more than one driver, as both drivers could be
> unbound/bound, driver should not end up getting stale media device that is
> on its way out. Moving the unregistered media device to to_delete_list helps
> this case as well.
> 
> I ran bind/unbind loop tests on uvcvideo, au0828, and snd-usb-audio while
> running application that does ioctls. Didn't see any use-after-free errors
> on media device. A couple of known issues seen:
> 
> 1. When application exits, cdev_put() gets called after media device is
>released. This is a known issue to resolve and Media Device Allocator
>can't solve this one.
> 2. When au0828 module is removed and then ioctls fail when cdev_get() looks
>for the owning module as au0828 is very often the module that owns the
>media devnode. This is a cdev related issue that needs to be resolved and
>Media Device Allocator can't solve this one.
> 
> Shuah Khan (5):
>   media: Add Media Device Allocator API
>   media: Add driver count to keep track of media device registrations
>   media: uvcvideo change to use Media Device Allocator API
>   media: au0828 change to use Media Device Allocator API
>   sound/usb: Use Media Controller API to share media resources

I don't think we need to include usb-audio patch at this stage yet.
The most important thing for now is to improve / stabilize the API
itself so that other drivers can use it as is.  Once when the API is
really stabilized, we create a solid git branch that may be based for
multiple subsystems, and I'll merge usb-audio stuff through sound git
tree.

Also, the previous usb-audio MC implementation had a few serious bugs,
including quirk NULL dereference.  See the bugzilla below for some fix
patches to 4.6-rc1:
  https://bugzilla.kernel.org/show_bug.cgi?id=115561
Feel free to fold them in, if they are still valid.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html