[PATCH] Staging: media: davinci_vpfe: Fix spelling error on a comment

[Manuel Rodriguez]

Fix spelling error on a comment, change 'wether' to 'whether'

Signed-off-by: Manuel Rodriguez 
---
 drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c 
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 0a65405..e4b953a 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -195,7 +195,7 @@ static int vpfe_update_pipe_state(struct vpfe_video_device 
*video)
return 0;
 }
 
-/* checks wether pipeline is ready for enabling */
+/* checks whether pipeline is ready for enabling */
 int vpfe_video_is_pipe_ready(struct vpfe_pipeline *pipe)
 {
int i;
-- 
1.9.1

--
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: How to see the content of my device's EEPROM?

[Olli Salonen]

Hi,

Load the module with i2c_debug on:

From: em28xx-i2c.c:

693 if (i2c_debug) {
694 /* Display eeprom content */
695 print_hex_dump(KERN_INFO, "eeprom ", DUMP_PREFIX_OFFSET,
69616, 1, data, len, true);
697
698 if (dev->eeprom_addrwidth_16bit)
699 em28xx_info("eeprom %06x: ... (skipped)\n", 256);
700 }

modprobe em28xx i2c_debug=1 should do it.

Cheers,
-olli

On 8 March 2016 at 05:03, Alexandre-Xavier Labonté-Lamoureux
 wrote:
> Hello everyone,
>
> On the kernel version 4.3.3, when I do dmesg to see the content of the
> EEPROM of the device that I just connected, I don't see it.
>
> I only see this: https://justpaste.it/qchd
>
> On older kernel versions like 3.10, I had what I wanted:
> https://justpaste.it/qchh
>
> i2c eeprom 00: 1a eb 67 95 1a eb 51 50 50 00 20 03 82 34 6a 04
> i2c eeprom 10: 6e 14 27 57 06 02 00 00 00 00 00 00 00 00 00 00
> i2c eeprom 20: 02 00 01 00 f0 10 01 00 b8 00 00 00 5b 00 00 00
> i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00
> i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 c4 00 00
> i2c eeprom 50: 00 a2 00 87 81 00 00 00 00 00 00 00 00 00 00 00
> i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 04 03 30 00 14 03
> i2c eeprom 70: 49 00 4f 00 4e 00 20 00 41 00 75 00 64 00 69 00
> i2c eeprom 80: 6f 00 34 03 49 00 4f 00 4e 00 20 00 41 00 75 00
> i2c eeprom 90: 64 00 69 00 6f 00 20 00 55 00 53 00 42 00 20 00
> i2c eeprom a0: 32 00 38 00 36 00 31 00 20 00 44 00 65 00 76 00
> i2c eeprom b0: 69 00 63 00 65 00 00 00 00 00 00 00 00 00 00 00
> i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> Why do newer kernels print less information to dmesg? How do I do if I want
> to see the content of my EEPROM on kernel v4.3.3 ?
>
> Thanks in advance,
> Alexandre-Xavier
--
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: Kernel docs: muddying the waters a bit

[Russel Winder]

On Fri, 2016-03-04 at 09:46 +0200, Jani Nikula wrote:
> […]
> If we're talking about the same asciidoctor (http://asciidoctor.org/)
> it's written in ruby but you can apparently run it in JVM using
> JRuby. Calling it Java-based is misleading.

Indeed, I was somewhat imprecise. Thanks to the work mostly of Charles
Nutter, JRuby is invariably a faster platform for Ruby code than Ruby
is. So yes ASCIIDoctor is JVM-based via JRuby, not Java-based.

The real point here is that in a move from DocBook/XML as a
documentation source, ASCIIDoctor is an excellent choice.

-- 
Russel.=Dr
 Russel Winder  t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net41 
Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.ukLondon SW11 
1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

cron job: media_tree daily build: OK

[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:   Tue Mar  8 04:00:26 CET 2016
git branch: test
git hash:   de08b5a8be0df1eb7c796b0fe6b30cf1d03d14a6
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-51-ga53cea2
smatch version: v0.5.0-3228-g5cf65ab
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-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-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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

How to see the content of my device's EEPROM?

[Alexandre-Xavier Labonté-Lamoureux]

Hello everyone,

On the kernel version 4.3.3, when I do dmesg to see the content of the
EEPROM of the device that I just connected, I don't see it.

I only see this: https://justpaste.it/qchd

On older kernel versions like 3.10, I had what I wanted:
https://justpaste.it/qchh

i2c eeprom 00: 1a eb 67 95 1a eb 51 50 50 00 20 03 82 34 6a 04
i2c eeprom 10: 6e 14 27 57 06 02 00 00 00 00 00 00 00 00 00 00
i2c eeprom 20: 02 00 01 00 f0 10 01 00 b8 00 00 00 5b 00 00 00
i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00
i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 c4 00 00
i2c eeprom 50: 00 a2 00 87 81 00 00 00 00 00 00 00 00 00 00 00
i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 04 03 30 00 14 03
i2c eeprom 70: 49 00 4f 00 4e 00 20 00 41 00 75 00 64 00 69 00
i2c eeprom 80: 6f 00 34 03 49 00 4f 00 4e 00 20 00 41 00 75 00
i2c eeprom 90: 64 00 69 00 6f 00 20 00 55 00 53 00 42 00 20 00
i2c eeprom a0: 32 00 38 00 36 00 31 00 20 00 44 00 65 00 76 00
i2c eeprom b0: 69 00 63 00 65 00 00 00 00 00 00 00 00 00 00 00
i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Why do newer kernels print less information to dmesg? How do I do if I want
to see the content of my EEPROM on kernel v4.3.3 ?

Thanks in advance,
Alexandre-Xavier

[PATCH v2] media: rcar_vin: Use ARCH_RENESAS

[Simon Horman]

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Signed-off-by: Simon Horman 

---
Based on media-tree/next

v2
* Break out of a (slightly) larger patch
---
 drivers/media/platform/soc_camera/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 355298989dd8..08db3b040bbe 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -28,7 +28,7 @@ config VIDEO_PXA27x
 config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) support"
depends on VIDEO_DEV && SOC_CAMERA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
-- 
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

[PATCH v2] media: sh_mobile_ceu_camera: Remove dependency on SUPERH

[Simon Horman]

A dependency on ARCH_SHMOBILE seems to be the best option for
sh_mobile_ceu_camera:

* For Super H based SoCs: sh_mobile_ceu is used on SH_AP325RXA, SH_ECOVEC,
  SH_KFR2R09, SH_MIGOR, and SH_7724_SOLUTION_ENGINE which depend on
  CPU_SUBTYPE_SH7722, CPU_SUBTYPE_SH7723, or CPU_SUBTYPE_SH7724 which all
  select ARCH_SHMOBILE.

* For ARM Based SoCs: Since the removal of legacy (non-multiplatform)
  support this driver has not been used by any Renesas ARM based SoCs.
  The Renesas ARM based SoCs currently select ARCH_SHMOBILE, however,
  it is planned that this will no longer be the case.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Thanks to Geert Uytterhoeven for analysis and portions of the
change log text.

Cc: Geert Uytterhoeven 
Signed-off-by: Simon Horman 

--
Based on media-tree/next

v2
* Break out of a (slightly) larger patch
* Re-work to drop SUPERH dependency rather than replacing
  ARCH_SHMOBILE with ARCH_RENESAS.
---
 drivers/media/platform/soc_camera/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 08db3b040bbe..83029a4854ae 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -45,7 +45,7 @@ config VIDEO_SH_MOBILE_CSI2
 config VIDEO_SH_MOBILE_CEU
tristate "SuperH Mobile CEU Interface driver"
depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK
-   depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
+   depends on ARCH_SHMOBILE || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
-- 
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: [PATCH] media: sh_mobile_ceu_camera, rcar_vin: Use ARCH_RENESAS

[Simon Horman]

On Mon, Mar 07, 2016 at 08:53:56AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> Oops, seems I dropped all CCs in my earlier reply. Fixing up...
> 
> On Mon, Mar 7, 2016 at 2:28 AM, Simon Horman  wrote:
> > On Thu, Mar 03, 2016 at 09:40:07AM +0100, Geert Uytterhoeven wrote:
> >> On Thu, Mar 3, 2016 at 2:52 AM, Simon Horman  
> >> wrote:
> >> > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> >> >
> >> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> >> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a 
> >> > more
> >> > appropriate name than SHMOBILE for the majority of Renesas ARM based 
> >> > SoCs.
> >> >
> >> > Signed-off-by: Simon Horman 
> >>
> >> > --- a/drivers/media/platform/soc_camera/Kconfig
> >> > +++ b/drivers/media/platform/soc_camera/Kconfig
> >> > @@ -36,7 +36,7 @@ config VIDEO_PXA27x
> >> >  config VIDEO_RCAR_VIN
> >> > tristate "R-Car Video Input (VIN) support"
> >> > depends on VIDEO_DEV && SOC_CAMERA
> >> > -   depends on ARCH_SHMOBILE || COMPILE_TEST
> >> > +   depends on ARCH_RENESAS || COMPILE_TEST
> >>
> >> OK
> >>
> >> >>  config VIDEO_SH_MOBILE_CEU
> >> > tristate "SuperH Mobile CEU Interface driver"
> >> > depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK
> >> > -   depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
> >> > +   depends on ARCH_RENESAS || SUPERH || COMPILE_TEST
> >>
> >> I think dropping the SUPERH dependency is the right approach here, as all
> >> SuperH platforms using this driver select ARCH_SHMOBILE.
> >>
> >> "sh_mobile_ceu" is used on SH_AP325RXA, SH_ECOVEC, SH_KFR2R09, SH_MIGOR,
> >> and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722,
> >>  CPU_SUBTYPE_SH7723, or
> >> CPU_SUBTYPE_SH7724, and all three select ARCH_SHMOBILE.
> >
> > Dropping SUPERH seems fine to me. But in that case I think the following
> > would be best as I would like to stop selecting ARCH_SHMOBILE for
> > the ARM SoCs.
> >
> > depends on ARCH_RENESAS || ARCH_SHMOBILE || COMPILE_TEST
> 
> Do we need this driver with ARCH_RENESAS? It does not support DT.
> 
> R8a7740 has the sh_mobile_ceu hardware, but support for it was dropped with
> r8a7740/armadillo legacy removal.

Silly me, no it is not needed.
--
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 v5 22/22] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

On 03/05/2016 03:00 AM, Mauro Carvalho Chehab wrote:
> Em Wed,  2 Mar 2016 09:50:31 -0700
> Shuah Khan  escreveu:
> 
>> Change ALSA driver to use Media Controller API to
>> share media resources with DVB and V4L2 drivers
>> on a AU0828 media device. Media Controller specific
>> initialization is done after sound card is registered.
>> ALSA creates Media interface and entity function graph
>> nodes for Control, Mixer, PCM Playback, and PCM Capture
>> devices.
>>
>> snd_usb_hw_params() will call Media Controller enable
>> source handler interface to request the media resource.
>> If resource request is granted, it will release it from
>> snd_usb_hw_free(). If resource is busy, -EBUSY is returned.
>>
>> Media specific cleanup is done in usb_audio_disconnect().
>>
>> Signed-off-by: Shuah Khan 
>> Acked-by: Takashi Iwai 
> 
> Shuah, by looking at the produced graphs:
>   https://mchehab.fedorapeople.org/mc-next-gen/au0828_test/
> 
> I'm noticing the lack of ALSA I/O entities in the diagram
> (MEDIA_ENT_F_AUDIO_CAPTURE). The mixer there is not connected.
> 
> Could you please check what's happening?
> 
> Those are the relevant dmesg data:
> 
> [   19.017276] usbcore: registered new interface driver snd-usb-audio
> [  230.706102] Linux video capture interface: v2.00
> [  230.856983] au0828: au0828 driver loaded
> [  231.230612] au0828: i2c bus registered
> [  231.822006] tveeprom 5-0050: Hauppauge model 72001, rev E1H3, serial# 
> 4035199481
> [  231.822991] tveeprom 5-0050: MAC address is 00:0d:fe:84:41:f9
> [  231.823955] tveeprom 5-0050: tuner model is Xceive XC5000C (idx 173, type 
> 88)
> [  231.824782] tveeprom 5-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 
> 0x88)
> [  231.825272] tveeprom 5-0050: audio processor is AU8522 (idx 44)
> [  231.825276] tveeprom 5-0050: decoder processor is AU8522 (idx 42)
> [  231.825280] tveeprom 5-0050: has no radio, has IR receiver, has no IR 
> transmitter
> [  231.825283] au0828: hauppauge_eeprom: hauppauge eeprom: model=72001
> [  231.857567] au8522 5-0047: creating new instance
> [  231.857879] au8522_decoder creating new instance...
> [  231.910525] tuner 5-0061: Setting mode_mask to 0x06
> [  231.910532] tuner 5-0061: tuner 0x61: Tuner type absent
> [  231.910535] tuner 5-0061: Tuner -1 found with type(s) Radio TV.
> [  231.911343] tuner 5-0061: Calling set_type_addr for type=88, addr=0x61, 
> mode=0x04, config=a0e64100
> [  231.911347] tuner 5-0061: defining GPIO callback
> [  231.934896] xc5000 5-0061: creating new instance
> [  231.954664] xc5000: Successfully identified at address 0x61
> [  231.954987] xc5000: Firmware has not been loaded previously
> [  231.955327] tuner 5-0061: type set to Xceive XC5000
> [  231.955330] tuner 5-0061: au0828 tuner I2C addr 0xc2 with type 88 used for 
> 0x04
> [  233.622614] au8522 5-0047: attaching existing instance
> [  233.636061] xc5000 5-0061: attaching existing instance
> [  233.645775] xc5000: Successfully identified at address 0x61
> [  233.646034] xc5000: Firmware has not been loaded previously
> [  233.646461] DVB: registering new adapter (au0828)
> [  233.647575] usb 2-3.3: DVB: registering adapter 0 frontend 0 (Auvitek 
> AU8522 QAM/8VSB Frontend)...
> [  233.648344] dvb_create_media_entity: media entity 'Auvitek AU8522 QAM/8VSB 
> Frontend' registered.
> [  233.656105] dvb_create_media_entity: media entity 'dvb-demux' registered.
> [  234.166644] IR keymap rc-hauppauge not found
> [  234.166962] Registered IR keymap rc-empty
> [  234.178055] input: au0828 IR (Hauppauge HVR950Q) as 
> /devices/pci:00/:00:14.0/usb2/2-3/2-3.3/rc/rc0/input14
> [  234.203311] rc rc0: au0828 IR (Hauppauge HVR950Q) as 
> /devices/pci:00/:00:14.0/usb2/2-3/2-3.3/rc/rc0
> [  234.207828] au0828: Remote controller au0828 IR (Hauppauge HVR950Q) 
> initalized
> [  234.208270] au0828: Registered device AU0828 [Hauppauge HVR950Q]
> [  234.212073] usbcore: registered new interface driver au0828
> [  234.230371] lirc_dev: IR Remote Control driver registered, major 243 
> [  234.257555] rc rc0: lirc_dev: driver ir-lirc-codec (au0828-input) 
> registered at minor = 0
> [  234.257960] IR LIRC bridge handler initialized
> 
> (as au0828 is blacklisted, snd-usb-audio was probed first)
> 
> 
> 
> I'm also getting some other weird behavior when removing/reinserting
> the modules a few times. OK, officially we don't support it, but,
> as devices can be bind/unbind all the times, removing modules is
> a way to simulate such things. Also, I use it a lot while testing
> USB drivers ;)
> 
> This one is after removing both the media drivers and snd-usb-audio, 
> and then modprobing snd-usb-audio:
> 

I did see some issues when I did the following sequence:

- blacklisted au0828 and snd-usb-audio was probed first
  graph is good just with audio entities as expected
- modprobed au0828 - graph looks good.
- rmmod au0828 - no problems seen in dmesg
- 

Re: [PATCH v5 22/22] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

On 03/05/2016 03:00 AM, Mauro Carvalho Chehab wrote:
> Em Wed,  2 Mar 2016 09:50:31 -0700
> Shuah Khan  escreveu:
> 
>> Change ALSA driver to use Media Controller API to
>> share media resources with DVB and V4L2 drivers
>> on a AU0828 media device. Media Controller specific
>> initialization is done after sound card is registered.
>> ALSA creates Media interface and entity function graph
>> nodes for Control, Mixer, PCM Playback, and PCM Capture
>> devices.
>>
>> snd_usb_hw_params() will call Media Controller enable
>> source handler interface to request the media resource.
>> If resource request is granted, it will release it from
>> snd_usb_hw_free(). If resource is busy, -EBUSY is returned.
>>
>> Media specific cleanup is done in usb_audio_disconnect().
>>
>> Signed-off-by: Shuah Khan 
>> Acked-by: Takashi Iwai 
> 
> Shuah, by looking at the produced graphs:
>   https://mchehab.fedorapeople.org/mc-next-gen/au0828_test/
> 
> I'm noticing the lack of ALSA I/O entities in the diagram
> (MEDIA_ENT_F_AUDIO_CAPTURE). The mixer there is not connected.
> 
> Could you please check what's happening?
> 
> Those are the relevant dmesg data:
> 
> [   19.017276] usbcore: registered new interface driver snd-usb-audio
> [  230.706102] Linux video capture interface: v2.00
> [  230.856983] au0828: au0828 driver loaded
> [  231.230612] au0828: i2c bus registered
> [  231.822006] tveeprom 5-0050: Hauppauge model 72001, rev E1H3, serial# 
> 4035199481
> [  231.822991] tveeprom 5-0050: MAC address is 00:0d:fe:84:41:f9
> [  231.823955] tveeprom 5-0050: tuner model is Xceive XC5000C (idx 173, type 
> 88)
> [  231.824782] tveeprom 5-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 
> 0x88)
> [  231.825272] tveeprom 5-0050: audio processor is AU8522 (idx 44)
> [  231.825276] tveeprom 5-0050: decoder processor is AU8522 (idx 42)
> [  231.825280] tveeprom 5-0050: has no radio, has IR receiver, has no IR 
> transmitter
> [  231.825283] au0828: hauppauge_eeprom: hauppauge eeprom: model=72001
> [  231.857567] au8522 5-0047: creating new instance
> [  231.857879] au8522_decoder creating new instance...
> [  231.910525] tuner 5-0061: Setting mode_mask to 0x06
> [  231.910532] tuner 5-0061: tuner 0x61: Tuner type absent
> [  231.910535] tuner 5-0061: Tuner -1 found with type(s) Radio TV.
> [  231.911343] tuner 5-0061: Calling set_type_addr for type=88, addr=0x61, 
> mode=0x04, config=a0e64100
> [  231.911347] tuner 5-0061: defining GPIO callback
> [  231.934896] xc5000 5-0061: creating new instance
> [  231.954664] xc5000: Successfully identified at address 0x61
> [  231.954987] xc5000: Firmware has not been loaded previously
> [  231.955327] tuner 5-0061: type set to Xceive XC5000
> [  231.955330] tuner 5-0061: au0828 tuner I2C addr 0xc2 with type 88 used for 
> 0x04
> [  233.622614] au8522 5-0047: attaching existing instance
> [  233.636061] xc5000 5-0061: attaching existing instance
> [  233.645775] xc5000: Successfully identified at address 0x61
> [  233.646034] xc5000: Firmware has not been loaded previously
> [  233.646461] DVB: registering new adapter (au0828)
> [  233.647575] usb 2-3.3: DVB: registering adapter 0 frontend 0 (Auvitek 
> AU8522 QAM/8VSB Frontend)...
> [  233.648344] dvb_create_media_entity: media entity 'Auvitek AU8522 QAM/8VSB 
> Frontend' registered.
> [  233.656105] dvb_create_media_entity: media entity 'dvb-demux' registered.
> [  234.166644] IR keymap rc-hauppauge not found
> [  234.166962] Registered IR keymap rc-empty
> [  234.178055] input: au0828 IR (Hauppauge HVR950Q) as 
> /devices/pci:00/:00:14.0/usb2/2-3/2-3.3/rc/rc0/input14
> [  234.203311] rc rc0: au0828 IR (Hauppauge HVR950Q) as 
> /devices/pci:00/:00:14.0/usb2/2-3/2-3.3/rc/rc0
> [  234.207828] au0828: Remote controller au0828 IR (Hauppauge HVR950Q) 
> initalized
> [  234.208270] au0828: Registered device AU0828 [Hauppauge HVR950Q]
> [  234.212073] usbcore: registered new interface driver au0828
> [  234.230371] lirc_dev: IR Remote Control driver registered, major 243 
> [  234.257555] rc rc0: lirc_dev: driver ir-lirc-codec (au0828-input) 
> registered at minor = 0
> [  234.257960] IR LIRC bridge handler initialized
> 
> (as au0828 is blacklisted, snd-usb-audio was probed first)
> 
> 
> 
> I'm also getting some other weird behavior when removing/reinserting
> the modules a few times. OK, officially we don't support it, but,
> as devices can be bind/unbind all the times, removing modules is
> a way to simulate such things. Also, I use it a lot while testing
> USB drivers ;)
> 
> This one is after removing both the media drivers and snd-usb-audio, 
> and then modprobing snd-usb-audio:
> 

I did see some issues when I did the following sequence:

- blacklisted au0828 and snd-usb-audio was probed first
  graph is good just with audio entities as expected
- modprobed au0828 - graph looks good.
- rmmod au0828 - no problems seen in dmesg
- 

Re: [PATCH v5 22/22] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

On 03/07/2016 07:16 AM, Shuah Khan wrote:
> On 03/05/2016 03:00 AM, Mauro Carvalho Chehab wrote:
>> Em Wed,  2 Mar 2016 09:50:31 -0700
>> Shuah Khan  escreveu:
>>
>>> Change ALSA driver to use Media Controller API to
>>> share media resources with DVB and V4L2 drivers
>>> on a AU0828 media device. Media Controller specific
>>> initialization is done after sound card is registered.
>>> ALSA creates Media interface and entity function graph
>>> nodes for Control, Mixer, PCM Playback, and PCM Capture
>>> devices.
>>>
>>> snd_usb_hw_params() will call Media Controller enable
>>> source handler interface to request the media resource.
>>> If resource request is granted, it will release it from
>>> snd_usb_hw_free(). If resource is busy, -EBUSY is returned.
>>>
>>> Media specific cleanup is done in usb_audio_disconnect().
>>>
>>> Signed-off-by: Shuah Khan 
>>> Acked-by: Takashi Iwai 
>>
>> Shuah, by looking at the produced graphs:
>>  https://mchehab.fedorapeople.org/mc-next-gen/au0828_test/
>>
>> I'm noticing the lack of ALSA I/O entities in the diagram
>> (MEDIA_ENT_F_AUDIO_CAPTURE). The mixer there is not connected.
>>
>> Could you please check what's happening?
> 
> Mauro,
> 
> Did you pull in this patch that fixes the graph problem:
> 
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg95047.html
> 
> If you haven't, could you please pull this in.
> 

You do have the above patch in the latest linux_media
git. I couldn't reproduce the problem you are seeing.

Here is what I did.
- Blacklisted au0828 and forcing snd_usb_audio
  probe first. Then I generated a graph that shows just
  the audio nodes.
- And then did a modprobe and generated full graph.

https://drive.google.com/folderview?id=0B0NIL0BQg-AlejFpR19Cb1RGYVk=drive_web

I see that in you graph, mixer gets connected to decoder, but the rest
of the audio nodes are missing from the graph.

MEDIA_ENT_F_AUDIO_CAPTURE gets created from  snd_usb_pcm_open()
and gets deleted from free_substream(). Is it possible, for
some reason, either snd_usb_pcm_open() fails or free_substream()
is called?


thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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 0/2] [media] gspca_kinect: enable both video and depth streams

[Ulrik de Muelenaere]

Hi Hans,

On Mon, Mar 07, 2016 at 08:00:46PM +0100, Hans de Goede wrote:
> Hi Ulrik,
> 
> On 06-03-16 14:50, Ulrik de Muelenaere wrote:
> >Hello,
> >
> >The Kinect produces both a video and depth stream, but the current 
> >implementation of the
> >gspca_kinect subdriver requires a depth_mode parameter at probe time to 
> >select one of
> >the streams which will be exposed as a v4l device. This patchset allows both 
> >streams to
> >be accessed as separate video nodes.
> >
> >A possible solution which has been discussed in the past is to call 
> >gspca_dev_probe()
> >multiple times in order to create multiple video nodes. See the following 
> >mails:
> >
> >http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/26194/focus=26213
> >http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/76715/focus=78344
> >
> >In the second mail linked above, it was mentioned that gspca_dev_probe() 
> >cannot be
> >called multiple times for the same USB interface, since gspca_dev_probe2() 
> >stores a
> >pointer to the new gspca_dev as the interface's private data. This is 
> >required for
> >gspca_disconnect(), gspca_suspend() and gspca_resume(). As far as I can 
> >tell, this is
> >the only reason gspca_dev_probe() cannot be called multiple times.
> >
> >The first patch fixes this by storing other devices linked to the same 
> >interface as a
> >linked list. The second patch then calls gspca_dev_probe() twice in the 
> >gspca_kinect
> >subdriver, to create a video node for each stream.
> >
> >Some notes on error handling, which I think should be reviewed:
> >
> >* I could not test the gspca_suspend() and gspca_resume() functions. From my 
> >evaluation
> >   of the code, it seems that the only effect of returning an error code from
> >   gspca_resume() is that a message is logged. Therefore I decided to 
> > attempt to resume
> >   each gspca_dev when the interface is resumed, even if one fails. Bitwise 
> > OR seems
> >   like the best way to combine potentially multiple error codes.
> >
> >* In the gspca_kinect subdriver, if the second call to gspca_dev_probe() 
> >fails, the
> >   first video node will still be available. I handle this case by calling
> >   gspca_disconnect(), which worked when I was testing, but I am not sure if 
> > this is the
> >   correct way to handle it.
> 
> Thanks for the patch-set overall I like it, one thing which worries is me is
> that sd_start_video and sd_start_depth may race, which is esp. problematic
> taking into account that both start/stop the depth stream (see the comment
> about this in sd_start_video()) this will require some coordination,
> so you like need to do something a bit more advanced and create a shared
> data struct somewhere for coordination (and with a lock in it).
> 
> Likewise the v4l2 core is designed to have only one struct v4l2_device per
> struct device, so you need to modify probe2 to not call
> v4l2_device_register when it is called a second time for the same intf,
> and to make gspca_dev->vdev.v4l2_dev point to the v4l2_dev of the
> first gspca_dev registered.
> 
> You will also need some changes for this in gspca_disconnect, as you will
> need to do all the calls on _dev->v4l2_dev only for the
> first registered device there, and you will need to do all the
> calls in gspca_release except for the v4l2_device_unregister() in
> a loop like you're using in disconnect.
> 
> Note since you need a shared data struct anyways it might be easier to
> just use that (add some shared pointer to struct gspca_dev) for the array
> of gspca_devs rather then using the linked list, as for disconnect /
> release you will want to use the first registered gspca_dev to get
> the v4l2_dev address, and your linked approach gives you the last.

Thanks for the input. I'll start working on your suggestions.

Regards,
Ulrik

> 
> Regards,
> 
> Hans
> 
> 
> >
> >Regards,
> >Ulrik
> >
> >Ulrik de Muelenaere (2):
> >   [media] gspca: allow multiple probes per USB interface
> >   [media] gspca_kinect: enable both video and depth streams
> >
> >  drivers/media/usb/gspca/gspca.c  | 129 
> > +++
> >  drivers/media/usb/gspca/gspca.h  |   1 +
> >  drivers/media/usb/gspca/kinect.c |  28 +
> >  3 files changed, 91 insertions(+), 67 deletions(-)
> >
--
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 0/2] [media] gspca_kinect: enable both video and depth streams

[Hans de Goede]

Hi Ulrik,

On 06-03-16 14:50, Ulrik de Muelenaere wrote:

Hello,

The Kinect produces both a video and depth stream, but the current 
implementation of the
gspca_kinect subdriver requires a depth_mode parameter at probe time to select 
one of
the streams which will be exposed as a v4l device. This patchset allows both 
streams to
be accessed as separate video nodes.

A possible solution which has been discussed in the past is to call 
gspca_dev_probe()
multiple times in order to create multiple video nodes. See the following mails:

http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/26194/focus=26213
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/76715/focus=78344

In the second mail linked above, it was mentioned that gspca_dev_probe() cannot 
be
called multiple times for the same USB interface, since gspca_dev_probe2() 
stores a
pointer to the new gspca_dev as the interface's private data. This is required 
for
gspca_disconnect(), gspca_suspend() and gspca_resume(). As far as I can tell, 
this is
the only reason gspca_dev_probe() cannot be called multiple times.

The first patch fixes this by storing other devices linked to the same 
interface as a
linked list. The second patch then calls gspca_dev_probe() twice in the 
gspca_kinect
subdriver, to create a video node for each stream.

Some notes on error handling, which I think should be reviewed:

* I could not test the gspca_suspend() and gspca_resume() functions. From my 
evaluation
   of the code, it seems that the only effect of returning an error code from
   gspca_resume() is that a message is logged. Therefore I decided to attempt 
to resume
   each gspca_dev when the interface is resumed, even if one fails. Bitwise OR 
seems
   like the best way to combine potentially multiple error codes.

* In the gspca_kinect subdriver, if the second call to gspca_dev_probe() fails, 
the
   first video node will still be available. I handle this case by calling
   gspca_disconnect(), which worked when I was testing, but I am not sure if 
this is the
   correct way to handle it.


Thanks for the patch-set overall I like it, one thing which worries is me is
that sd_start_video and sd_start_depth may race, which is esp. problematic
taking into account that both start/stop the depth stream (see the comment
about this in sd_start_video()) this will require some coordination,
so you like need to do something a bit more advanced and create a shared
data struct somewhere for coordination (and with a lock in it).

Likewise the v4l2 core is designed to have only one struct v4l2_device per
struct device, so you need to modify probe2 to not call
v4l2_device_register when it is called a second time for the same intf,
and to make gspca_dev->vdev.v4l2_dev point to the v4l2_dev of the
first gspca_dev registered.

You will also need some changes for this in gspca_disconnect, as you will
need to do all the calls on _dev->v4l2_dev only for the
first registered device there, and you will need to do all the
calls in gspca_release except for the v4l2_device_unregister() in
a loop like you're using in disconnect.

Note since you need a shared data struct anyways it might be easier to
just use that (add some shared pointer to struct gspca_dev) for the array
of gspca_devs rather then using the linked list, as for disconnect /
release you will want to use the first registered gspca_dev to get
the v4l2_dev address, and your linked approach gives you the last.

Regards,

Hans




Regards,
Ulrik

Ulrik de Muelenaere (2):
   [media] gspca: allow multiple probes per USB interface
   [media] gspca_kinect: enable both video and depth streams

  drivers/media/usb/gspca/gspca.c  | 129 +++
  drivers/media/usb/gspca/gspca.h  |   1 +
  drivers/media/usb/gspca/kinect.c |  28 +
  3 files changed, 91 insertions(+), 67 deletions(-)


--
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: i2c/adp1653: fix check of devm_gpiod_get() error code

[Vladimir Zapolskiy]

The devm_gpiod_get() function returns either a valid pointer to
struct gpio_desc or ERR_PTR() error value, check for NULL is bogus.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/media/i2c/adp1653.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index fb7ed73..9e1731c 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -466,9 +466,9 @@ static int adp1653_of_init(struct i2c_client *client,
of_node_put(child);
 
pd->enable_gpio = devm_gpiod_get(>dev, "enable", GPIOD_OUT_LOW);
-   if (!pd->enable_gpio) {
+   if (IS_ERR(pd->enable_gpio)) {
dev_err(>dev, "Error getting GPIO\n");
-   return -EINVAL;
+   return PTR_ERR(pd->enable_gpio);
}
 
return 0;
-- 
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: videobuf2-dma-sg and multiple planes semantics

[Robert Jarzmik]

Robert Jarzmik  writes:

> Hi,
>
> I've been converting pxa_camera driver from videobuf to videobuf2, and I have 
> a
> question about multiple plane semantics.
>
> I have a case where I have 3 planes for a yuv422 capture :
>  - 1 Y plane (total_size / 2 bytes)
>  - 1 U plane (total_size / 4 bytes)
>  - 1 V plane (total_size / 4 bytes)
>
> I would have expected vb2_dma_sg_plane_desc(vb, i) to return me 3 different
> sg_tables, one for each plane. I would have been then able to feed them to 3
> dmaengine channels (this is the case for pxa27x platform), so that the 3 
> planes
> are filled in concurrently.
>
> My understanding is that videobuf2-dma-sg has only 1 sg_table, which seems to 
> be
> enforced by vb2_dma_sg_cookie(), so the question is : is it on purpose, and 
> how
> do the multiple planes are handled within videobuf2-dma-sg ?

Oh I think I was a bit mislead, because I was looking at it from a userspace
perspective. The in-kernel pxa_camera has 3 different sg_tables all right.

The issue is rather that from userspace, the call to VIDIOC_QUERYBUF, which is
an old userspace program (such as capture_example.c, year 2008 version), returns
only half of the total_size.

Now looking at it more closely, I think this is because :
 - in videobuf2-v4l2.c
 - as my old program doesn't set the V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE bit
 - __fill_v4l2_buffer() returns b->length = vb->planes[0].length

I would have expected to have b->length = sum(vb->planes[i].length).

Could someone explain to me the rationale behind returning only the first plane
length instead of the sum of all planes lengthes ?

Cheers.

-- 
Robert
--
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

videobuf2-dma-sg and multiple planes semantics

[Robert Jarzmik]

Hi,

I've been converting pxa_camera driver from videobuf to videobuf2, and I have a
question about multiple plane semantics.

I have a case where I have 3 planes for a yuv422 capture :
 - 1 Y plane (total_size / 2 bytes)
 - 1 U plane (total_size / 4 bytes)
 - 1 V plane (total_size / 4 bytes)

I would have expected vb2_dma_sg_plane_desc(vb, i) to return me 3 different
sg_tables, one for each plane. I would have been then able to feed them to 3
dmaengine channels (this is the case for pxa27x platform), so that the 3 planes
are filled in concurrently.

My understanding is that videobuf2-dma-sg has only 1 sg_table, which seems to be
enforced by vb2_dma_sg_cookie(), so the question is : is it on purpose, and how
do the multiple planes are handled within videobuf2-dma-sg ?

Cheers.

--
Robert
--
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: i.mx6 camera interface (CSI) and mainline kernel

[Tim Harvey]

On Thu, Mar 3, 2016 at 9:45 AM, Steve Longerbeam
 wrote:
> Hi Philippe,
>
> On 03/03/2016 12:36 AM, Philippe De Muyter wrote:
>>
>> Just to be sure : do you mean  https://github.com/slongerbeam/mediatree.git
>> or something else ?
>
> Sorry, yes I meant https://github.com/slongerbeam/mediatree.git.
>
>>
 So far I have retested video capture with the SabreAuto/ADV7180 and
 the SabreSD/OV5640-mipi-csi2, and video capture is working fine on
 those platforms.

 There is also a mem2mem that should work fine, but haven't tested yet.

 I removed camera preview support. At Mentor Graphics we have made
 quite a few changes to ipu-v3 driver to allow camera preview to initialize
 and control an overlay display plane independently of imx-drm, by adding
 a subsystem independent ipu-plane sub-unit. Note we also have a video
 output overlay driver that also makes use of ipu-plane. But those changes 
 are
 extensive and touch imx-drm as well as ipu-v3, so I am leaving camera 
 preview
 and the output overlay driver out (in fact, camera preview is not of much
 utility so I probably won't bring it back in upstream version).

 The video capture driver is not quite ready for upstream review yet. It 
 still:

 - uses the old cropping APIs but should move forward to selection APIs.

 - uses custom sensor subdev drivers for ADV7180 and OV564x. Still
   need to switch to upstream subdevs.
>> Is it only a problem of those sensor drivers (which exact files ?) or
>> is it a problem of the capture driver itself ?
>
> The camera interface driver (drivers/staging/media/imx6/capture/mx6-camif.c)
> is binding to these subdevs:
>
> drivers/staging/media/imx6/capture/adv7180.c
> drivers/staging/media/imx6/capture/ov5642.c
> drivers/staging/media/imx6/capture/ov5640-mipi.c
>
> But instead should use the subdevs under drivers/media/i2c, specifically:
>
> drivers/media/i2c/adv7180.c (and adding whatever standard subdev features
> the imx6 interface driver requires).
>
> There is a drivers/media/i2c/soc_camera/ov5642.c, but there is no mipi-csi2
> capable subdev for the ov5640 with the mipi-csi2 interface, so that would have
> to be created.
>

Steve,

I've built your mx6-media-staging branch and added device-tree config
for the Gateworks Ventana boards which have an on-board ADV7180 and it
works great. I've tested it capturing frames via v4l2-ctl as well as
gstreamer.

Please let me know what kind of testing you need. I would love to see
this get mainlined!

Regards,

Tim

Tim Harvey - Principal Software Engineer
Gateworks Corporation - http://www.gateworks.com/
3026 S. Higuera St. San Luis Obispo CA 93401
805-781-2000
--
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: [TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes before %pa extension uses

[Ross Zwisler]

On Fri, Mar 04, 2016 at 11:46:32PM -0800, Joe Perches wrote:
> Since commit 3cab1e711297 ("lib/vsprintf: refactor duplicate code
> to special_hex_number()") %pa uses have been ouput with a 0x prefix.
> 
> These 0x prefixes in the formats are unnecessary.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/dma/at_hdmac_regs.h  | 2 +-
>  drivers/media/platform/ti-vpe/cal.c  | 2 +-
>  drivers/nvdimm/pmem.c| 2 +-
>  drivers/rapidio/devices/rio_mport_cdev.c | 4 ++--
>  drivers/rapidio/devices/tsi721.c | 8 
>  5 files changed, 9 insertions(+), 9 deletions(-)
<>
> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
> index 8d0b546..eb619d1 100644
> --- a/drivers/nvdimm/pmem.c
> +++ b/drivers/nvdimm/pmem.c
> @@ -172,7 +172,7 @@ static struct pmem_device *pmem_alloc(struct device *dev,
>  
>   if (!devm_request_mem_region(dev, pmem->phys_addr, pmem->size,
>   dev_name(dev))) {
> - dev_warn(dev, "could not reserve region [0x%pa:0x%zx]\n",
> + dev_warn(dev, "could not reserve region [%pa:0x%zx]\n",
>   >phys_addr, pmem->size);
>   return ERR_PTR(-EBUSY);
>   }

For the pmem part:
Acked-by: Ross Zwisler 
--
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: [TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes before %pa extension uses

[Vinod Koul]

On Fri, Mar 04, 2016 at 11:46:32PM -0800, Joe Perches wrote:
> Since commit 3cab1e711297 ("lib/vsprintf: refactor duplicate code
> to special_hex_number()") %pa uses have been ouput with a 0x prefix.
> 
> These 0x prefixes in the formats are unnecessary.
> 

For this:
>  drivers/dma/at_hdmac_regs.h  | 2 +-

Acked-by: Vinod Koul 

-- 
~Vinod
--
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 0/2] [media] exynos4-is: Trivial fixes for DT port/endpoint parse logic

[Javier Martinez Canillas]

Hello Sylwester,

On 03/07/2016 06:24 AM, Sylwester Nawrocki wrote:
> Hi Javier, Krzysztof,
> 
> On 03/05/2016 05:35 AM, Krzysztof Kozlowski wrote:
>> 2016-03-05 5:20 GMT+09:00 Javier Martinez Canillas :
 Hello,

 This series have two trivial fixes for issues that I noticed while
 reading as a reference the driver's functions that parse the graph
 port and endpoints nodes.

 It was only compile tested because I don't have access to a Exynos4
 hardware to test the DT parsing, but the patches are very simple.
>>
>> Not directly related, but similar: my previous two patches for missing
>> of_node_put [0] are unfortunately still waiting. Although I have
>> Exynos4 boards, but I don't have infrastructure/scripts to test it.
>>
>> Best regards,
>> Krzysztof
>>

I've reviewed Krzysztof and looks good to me.

>> [0] https://patchwork.linuxtv.org/patch/32707/
> 
> Thanks for the patches, I've delegated them to myself and I'm going to
> review/apply them this week.
>

Thanks, I just noticed another similar issue in the driver now and is
that fimc_is_parse_sensor_config() uses the same struct device_node *
for looking up the I2C sensor, port and endpoint and thus not doing a
of_node_put() for all the nodes on the error path.

I think the right fix is to have a separate struct device_node * for
each so their reference counter cand be incremented and decremented.

> --
> Regards,
> Sylwester
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: [RFT 2/2] [media] exynos4-is: Add missing port parent of_node_put on error paths

[Javier Martinez Canillas]

Hello Krzysztof,

On 01/25/2016 09:41 PM, Krzysztof Kozlowski wrote:
> In fimc_md_parse_port_node() remote port parent node is get with
> of_graph_get_remote_port_parent() but it is not put on error path.
> 
> Fixes: fa91f1056f17 ("[media] exynos4-is: Add support for asynchronous 
> subdevices registration")
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Not tested on hardware, only built+static checkers.
> ---
>  drivers/media/platform/exynos4-is/media-dev.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
> b/drivers/media/platform/exynos4-is/media-dev.c
> index de0977479327..d2e564878e06 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -385,8 +385,10 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
>   else
>   pd->fimc_bus_type = pd->sensor_bus_type;
>  
> - if (WARN_ON(index >= ARRAY_SIZE(fmd->sensor)))
> + if (WARN_ON(index >= ARRAY_SIZE(fmd->sensor))) {
> + of_node_put(rem);
>   return -EINVAL;
> + }
>  
>   fmd->sensor[index].asd.match_type = V4L2_ASYNC_MATCH_OF;
>   fmd->sensor[index].asd.match.of.node = rem;
> 

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 v5 22/22] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

On 03/05/2016 03:00 AM, Mauro Carvalho Chehab wrote:
> Em Wed,  2 Mar 2016 09:50:31 -0700
> Shuah Khan  escreveu:
> 
>> Change ALSA driver to use Media Controller API to
>> share media resources with DVB and V4L2 drivers
>> on a AU0828 media device. Media Controller specific
>> initialization is done after sound card is registered.
>> ALSA creates Media interface and entity function graph
>> nodes for Control, Mixer, PCM Playback, and PCM Capture
>> devices.
>>
>> snd_usb_hw_params() will call Media Controller enable
>> source handler interface to request the media resource.
>> If resource request is granted, it will release it from
>> snd_usb_hw_free(). If resource is busy, -EBUSY is returned.
>>
>> Media specific cleanup is done in usb_audio_disconnect().
>>
>> Signed-off-by: Shuah Khan 
>> Acked-by: Takashi Iwai 
> 
> Shuah, by looking at the produced graphs:
>   https://mchehab.fedorapeople.org/mc-next-gen/au0828_test/
> 
> I'm noticing the lack of ALSA I/O entities in the diagram
> (MEDIA_ENT_F_AUDIO_CAPTURE). The mixer there is not connected.
> 
> Could you please check what's happening?

Mauro,

Did you pull in this patch that fixes the graph problem:

https://www.mail-archive.com/linux-media@vger.kernel.org/msg95047.html

If you haven't, could you please pull this in.


> 
> Those are the relevant dmesg data:
> 
> [   19.017276] usbcore: registered new interface driver snd-usb-audio
> [  230.706102] Linux video capture interface: v2.00
> [  230.856983] au0828: au0828 driver loaded
> [  231.230612] au0828: i2c bus registered
> [  231.822006] tveeprom 5-0050: Hauppauge model 72001, rev E1H3, serial# 
> 4035199481
> [  231.822991] tveeprom 5-0050: MAC address is 00:0d:fe:84:41:f9
> [  231.823955] tveeprom 5-0050: tuner model is Xceive XC5000C (idx 173, type 
> 88)
> [  231.824782] tveeprom 5-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 
> 0x88)
> [  231.825272] tveeprom 5-0050: audio processor is AU8522 (idx 44)
> [  231.825276] tveeprom 5-0050: decoder processor is AU8522 (idx 42)
> [  231.825280] tveeprom 5-0050: has no radio, has IR receiver, has no IR 
> transmitter
> [  231.825283] au0828: hauppauge_eeprom: hauppauge eeprom: model=72001
> [  231.857567] au8522 5-0047: creating new instance
> [  231.857879] au8522_decoder creating new instance...
> [  231.910525] tuner 5-0061: Setting mode_mask to 0x06
> [  231.910532] tuner 5-0061: tuner 0x61: Tuner type absent
> [  231.910535] tuner 5-0061: Tuner -1 found with type(s) Radio TV.
> [  231.911343] tuner 5-0061: Calling set_type_addr for type=88, addr=0x61, 
> mode=0x04, config=a0e64100
> [  231.911347] tuner 5-0061: defining GPIO callback
> [  231.934896] xc5000 5-0061: creating new instance
> [  231.954664] xc5000: Successfully identified at address 0x61
> [  231.954987] xc5000: Firmware has not been loaded previously
> [  231.955327] tuner 5-0061: type set to Xceive XC5000
> [  231.955330] tuner 5-0061: au0828 tuner I2C addr 0xc2 with type 88 used for 
> 0x04
> [  233.622614] au8522 5-0047: attaching existing instance
> [  233.636061] xc5000 5-0061: attaching existing instance
> [  233.645775] xc5000: Successfully identified at address 0x61
> [  233.646034] xc5000: Firmware has not been loaded previously
> [  233.646461] DVB: registering new adapter (au0828)
> [  233.647575] usb 2-3.3: DVB: registering adapter 0 frontend 0 (Auvitek 
> AU8522 QAM/8VSB Frontend)...
> [  233.648344] dvb_create_media_entity: media entity 'Auvitek AU8522 QAM/8VSB 
> Frontend' registered.
> [  233.656105] dvb_create_media_entity: media entity 'dvb-demux' registered.
> [  234.166644] IR keymap rc-hauppauge not found
> [  234.166962] Registered IR keymap rc-empty
> [  234.178055] input: au0828 IR (Hauppauge HVR950Q) as 
> /devices/pci:00/:00:14.0/usb2/2-3/2-3.3/rc/rc0/input14
> [  234.203311] rc rc0: au0828 IR (Hauppauge HVR950Q) as 
> /devices/pci:00/:00:14.0/usb2/2-3/2-3.3/rc/rc0
> [  234.207828] au0828: Remote controller au0828 IR (Hauppauge HVR950Q) 
> initalized
> [  234.208270] au0828: Registered device AU0828 [Hauppauge HVR950Q]
> [  234.212073] usbcore: registered new interface driver au0828
> [  234.230371] lirc_dev: IR Remote Control driver registered, major 243 
> [  234.257555] rc rc0: lirc_dev: driver ir-lirc-codec (au0828-input) 
> registered at minor = 0
> [  234.257960] IR LIRC bridge handler initialized
> 
> (as au0828 is blacklisted, snd-usb-audio was probed first)
> 
> 
> 
> I'm also getting some other weird behavior when removing/reinserting
> the modules a few times. OK, officially we don't support it, but,
> as devices can be bind/unbind all the times, removing modules is
> a way to simulate such things. Also, I use it a lot while testing
> USB drivers ;)

I will do more testing on this. I didn't see any problems when
I fixed the graph patch above - I will do more on the latest
media branch today.

thanks,
-- Shuah

> 
> This one is after 

Re: [RFT 1/2] [media] exynos4-is: Add missing endpoint of_node_put on error paths

[Javier Martinez Canillas]

Hello Krzysztof,

On 01/25/2016 09:41 PM, Krzysztof Kozlowski wrote:
> In fimc_md_parse_port_node() endpoint node is get with of_get_next_child()
> but it is not put on error path.
> 
> Fixes: 56fa1a6a6a7d ("[media] s5p-fimc: Change the driver directory name to 
> exynos4-is")
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Not tested on hardware, only built+static checkers.
> ---
>  drivers/media/platform/exynos4-is/media-dev.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
> b/drivers/media/platform/exynos4-is/media-dev.c
> index f3b2dd30ec77..de0977479327 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -339,8 +339,10 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
>   return 0;
>  
>   v4l2_of_parse_endpoint(ep, );
> - if (WARN_ON(endpoint.base.port == 0) || index >= FIMC_MAX_SENSORS)
> + if (WARN_ON(endpoint.base.port == 0) || index >= FIMC_MAX_SENSORS) {
> + of_node_put(ep);
>   return -EINVAL;
> + }
>  
>   pd->mux_id = (endpoint.base.port - 1) & 0x1;
>  
> 

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: [TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes before %pa extension uses

[Bounine, Alexandre]

> From: Joe Perches [mailto:j...@perches.com]
> Sent: Saturday, March 05, 2016 2:47 AM
.
> Subject: [TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes
> before %pa extension uses
> 
> Since commit 3cab1e711297 ("lib/vsprintf: refactor duplicate code
> to special_hex_number()") %pa uses have been ouput with a 0x prefix.
> 
> These 0x prefixes in the formats are unnecessary.
> 
> Signed-off-by: Joe Perches 
> ---


>  drivers/rapidio/devices/rio_mport_cdev.c | 4 ++--
>  drivers/rapidio/devices/tsi721.c | 8 

For RapidIO part -
Acked-by: Alexandre Bounine 

.

> diff --git a/drivers/rapidio/devices/rio_mport_cdev.c
> b/drivers/rapidio/devices/rio_mport_cdev.c
> index a3369d1..211a67d 100644
> --- a/drivers/rapidio/devices/rio_mport_cdev.c
> +++ b/drivers/rapidio/devices/rio_mport_cdev.c
> @@ -2223,7 +2223,7 @@ static void mport_mm_open(struct vm_area_struct
> *vma)
>  {
>   struct rio_mport_mapping *map = vma->vm_private_data;
> 
> -rmcd_debug(MMAP, "0x%pad", >phys_addr);
> + rmcd_debug(MMAP, "%pad", >phys_addr);
>   kref_get(>ref);
>  }
> 
> @@ -2231,7 +2231,7 @@ static void mport_mm_close(struct vm_area_struct
> *vma)
>  {
>   struct rio_mport_mapping *map = vma->vm_private_data;
> 
> -rmcd_debug(MMAP, "0x%pad", >phys_addr);
> + rmcd_debug(MMAP, "%pad", >phys_addr);
>   mutex_lock(>md->buf_mutex);
>   kref_put(>ref, mport_release_mapping);
>   mutex_unlock(>md->buf_mutex);
> diff --git a/drivers/rapidio/devices/tsi721.c
> b/drivers/rapidio/devices/tsi721.c
> index b5b4556..4c20e99 100644
> --- a/drivers/rapidio/devices/tsi721.c
> +++ b/drivers/rapidio/devices/tsi721.c
> @@ -1101,7 +1101,7 @@ static int tsi721_rio_map_inb_mem(struct
> rio_mport *mport, dma_addr_t lstart,
>   ibw_start = lstart & ~(ibw_size - 1);
> 
>   tsi_debug(IBW, >pdev->dev,
> - "Direct (RIO_0x%llx -> PCIe_0x%pad), size=0x%x,
> ibw_start = 0x%llx",
> + "Direct (RIO_0x%llx -> PCIe_%pad), size=0x%x,
> ibw_start = 0x%llx",
>   rstart, , size, ibw_start);
> 
>   while ((lstart + size) > (ibw_start + ibw_size)) {
> @@ -1120,7 +1120,7 @@ static int tsi721_rio_map_inb_mem(struct
> rio_mport *mport, dma_addr_t lstart,
> 
>   } else {
>   tsi_debug(IBW, >pdev->dev,
> - "Translated (RIO_0x%llx -> PCIe_0x%pad), size=0x%x",
> + "Translated (RIO_0x%llx -> PCIe_%pad), size=0x%x",
>   rstart, , size);
> 
>   if (!is_power_of_2(size) || size < 0x1000 ||
> @@ -1215,7 +1215,7 @@ static int tsi721_rio_map_inb_mem(struct
> rio_mport *mport, dma_addr_t lstart,
>   priv->ibwin_cnt--;
> 
>   tsi_debug(IBW, >pdev->dev,
> - "Configured IBWIN%d (RIO_0x%llx -> PCIe_0x%pad),
> size=0x%llx",
> + "Configured IBWIN%d (RIO_0x%llx -> PCIe_%pad),
> size=0x%llx",
>   i, ibw_start, _start, ibw_size);
> 
>   return 0;
> @@ -1237,7 +1237,7 @@ static void tsi721_rio_unmap_inb_mem(struct
> rio_mport *mport,
>   int i;
> 
>   tsi_debug(IBW, >pdev->dev,
> - "Unmap IBW mapped to PCIe_0x%pad", );
> + "Unmap IBW mapped to PCIe_%pad", );
> 
>   /* Search for matching active inbound translation window */
>   for (i = 0; i < TSI721_IBWIN_NUM; i++) {
> --
> 2.6.3.368.gf34be46

--
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: Panic upon DViCO FusionHDTV DVB-T USB (TH7579) insertion

[Tim Connors]

Upgraded kernel to debian linux-image-4.4.0-1-amd64 (was a debian
prerelease 4.4.0-trunk-amd64), compiled in new media_build.git with this
patch:

diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index 24a457d9d803..def6d21d1445 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1501,18 +1501,18 @@
struct i2c_client *client;

/* remove I2C client for tuner */
-   client = st->i2c_client_tuner;
+/* client = st->i2c_client_tuner;
if (client) {
module_put(client->dev.driver->owner);
i2c_unregister_device(client);
-   }
+   } */

/* remove I2C client for demodulator */
-   client = st->i2c_client_demod;
+/* client = st->i2c_client_demod;
if (client) {
module_put(client->dev.driver->owner);
i2c_unregister_device(client);
-   }
+   } */

dvb_usb_device_exit(intf);
 }

but still get this oops when plugging in the device:

Mar  7 23:17:02 fs kernel: [ 1244.944047] usb 1-4: new high-speed USB device 
number 7 using ehci-pci
Mar  7 23:17:03 fs kernel: [ 1245.076521] usb 1-4: New USB device found, 
idVendor=0fe9, idProduct=db10
Mar  7 23:17:03 fs kernel: [ 1245.076532] usb 1-4: New USB device strings: 
Mfr=0, Product=0, SerialNumber=0
Mar  7 23:17:03 fs laptop-mode: Warning: Configuration file 
/etc/laptop-mode/conf.d/board-specific/*.conf is not readable, skipping.
Mar  7 23:17:03 fs laptop-mode: laptop-mode-tools is disabled in config file. 
Exiting
Mar  7 23:17:03 fs kernel: [ 1245.130250] media: Linux media interface: v0.10
Mar  7 23:17:03 fs kernel: [ 1245.135455] WARNING: You are using an 
experimental version of the media stack.
Mar  7 23:17:03 fs kernel: [ 1245.135455] #011As the driver is backported to an 
older kernel, it doesn't offer
Mar  7 23:17:03 fs kernel: [ 1245.135455] #011enough quality for its usage in 
production.
Mar  7 23:17:03 fs kernel: [ 1245.135455] #011Use it with care.
Mar  7 23:17:03 fs kernel: [ 1245.135455] Latest git patches (needed if you 
report a bug to linux-media@vger.kernel.org):
Mar  7 23:17:03 fs kernel: [ 1245.135455] 
#011de08b5a8be0df1eb7c796b0fe6b30cf1d03d14a6 [media] v4l: exynos4-is: Drop 
unneeded check when setting up fimc-lite links
Mar  7 23:17:03 fs kernel: [ 1245.135455] 
#01102650ebd2d306b661e6ad000e7981c7d8544f8f6 [media] v4l: vsp1: Check if an 
entity is a subdev with the right function
Mar  7 23:17:03 fs kernel: [ 1245.135455] 
#0110a82edd011f5cd3de1eded8fe1d78cef370b2083 [media] hide unused functions for 
!MEDIA_CONTROLLER
Mar  7 23:17:03 fs kernel: [ 1245.143211] WARNING: You are using an 
experimental version of the media stack.
Mar  7 23:17:03 fs kernel: [ 1245.143211] #011As the driver is backported to an 
older kernel, it doesn't offer
Mar  7 23:17:03 fs kernel: [ 1245.143211] #011enough quality for its usage in 
production.
Mar  7 23:17:03 fs kernel: [ 1245.143211] #011Use it with care.
Mar  7 23:17:03 fs kernel: [ 1245.143211] Latest git patches (needed if you 
report a bug to linux-media@vger.kernel.org):
Mar  7 23:17:03 fs kernel: [ 1245.143211] 
#011de08b5a8be0df1eb7c796b0fe6b30cf1d03d14a6 [media] v4l: exynos4-is: Drop 
unneeded check when setting up fimc-lite links
Mar  7 23:17:03 fs kernel: [ 1245.143211] 
#01102650ebd2d306b661e6ad000e7981c7d8544f8f6 [media] v4l: vsp1: Check if an 
entity is a subdev with the right function
Mar  7 23:17:03 fs kernel: [ 1245.143211] 
#0110a82edd011f5cd3de1eded8fe1d78cef370b2083 [media] hide unused functions for 
!MEDIA_CONTROLLER
Mar  7 23:17:03 fs kernel: [ 1245.153266] dvb-usb: found a 'DViCO FusionHDTV 
DVB-T USB (TH7579)' in cold state, will try to load a firmware
Mar  7 23:17:03 fs kernel: [ 1245.154688] usb 1-4: firmware: direct-loading 
firmware dvb-usb-bluebird-01.fw
Mar  7 23:17:03 fs kernel: [ 1245.154706] dvb-usb: downloading firmware from 
file 'dvb-usb-bluebird-01.fw'
Mar  7 23:17:03 fs kernel: [ 1245.218962] usbcore: registered new interface 
driver dvb_usb_cxusb
Mar  7 23:17:03 fs laptop-mode: Warning: Configuration file 
/etc/laptop-mode/conf.d/board-specific/*.conf is not readable, skipping.
Mar  7 23:17:03 fs laptop-mode: laptop-mode-tools is disabled in config file. 
Exiting
Mar  7 23:17:03 fs kernel: [ 1245.250660] usb 1-4: USB disconnect, device 
number 7
Mar  7 23:17:03 fs kernel: [ 1245.250727] dvb-usb: generic DVB-USB module 
successfully deinitialized and disconnected.
Mar  7 23:17:04 fs CRON[13170]: pam_unix(cron:session): session closed for user 
root
Mar  7 23:17:05 fs kernel: [ 1247.036080] usb 1-4: new high-speed USB device 
number 8 using ehci-pci
Mar  7 23:17:05 fs kernel: [ 1247.169608] usb 1-4: New USB device found, 
idVendor=0fe9, idProduct=db11
Mar  7 23:17:05 fs kernel: [ 1247.169622] usb 1-4: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0
Mar  7 23:17:05 fs kernel: [ 1247.169631] usb 1-4: Product: Bluebird
Mar  7 23:17:05 fs kernel: [ 1247.169640] usb 

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Mon, 7 Mar 2016 00:29:08 +0100
Johannes Stezenbach  escreveu:

> On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> > 
> > I converted one of the big tables to CSV. At least now it recognized
> > it as a table. Yet, the table was very badly formated:
> > 
> > https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
> > 
> > This is how this table should look like:
> > https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
> > 
> > Also, as this table has merged cells at the legend. I've no idea how
> > to tell sphinx to do that on csv format.
> > 
> > The RST files are on this git tree:
> > https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/  
> 
> Yeah, seems it can't do merged cells in csv.  Attached patch converts it
> back to grid table format and fixes the table definition.
> The html output looks usable, but clearly it is no fun to
> work with tables in Sphinx.

Yes, the output is OK, but, as you said, working with tables in
Sphinx is hard, and using asciiart for the kind of tables we have
is not nice.

> 
> Sphinx' latex writer can't handle nested tables, though.

Yeah, this is a big trouble that need to be solved if you're
willing to use Sphinx.

Btw, it crashes when trying to generate man pages:

Exception occurred:
  File "/usr/lib/python2.7/site-packages/docutils/writers/manpage.py", 
line 627, in depart_entry
self._active_table.append_cell(self.body[start:])
AttributeError: 'NoneType' object has no attribute 'append_cell'
The full traceback has been saved in /tmp/sphinx-err-04qRMz.log, if you 
want to report the issue to the developers.

So, if we're willing to use sphinx, someone should either fix
it to produce latex nexted table and fix it to generate manpages,
or we'll need to stick with just html output.

> Python's docutils rst2latex can, but that doesn't help here.
> rst2pdf also supports it.

At least here, rst2* scripts were unable to identify that the
index.rst had links to other rst documents. 

In the specific case of rst2latex, I got several errors like:

index.rst:21: (ERROR/3) Unknown interpreted text role "ref".


> But I have doubts such a large
> table would render OK in pdf without using landscape orientation.

Yeah, in the past, when we had pdf enabled for DocBook (e. g. when
media development was using a separate mercurial tree), I guess
we had tags changing the text orientation on a few tables that
would otherwise won't diplay fine, but I can't remember the dirty
details anymore.

> I have not tried because I used python3-sphinx but rst2pdf
> is only availble for Python2 in Debian so it does not integrate
> with Sphinx.
> 
> 
> Johannes


-- 
Thanks,
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: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Mon, 7 Mar 2016 09:48:26 +0100
Johannes Stezenbach  escreveu:

> On Mon, Mar 07, 2016 at 12:29:08AM +0100, Johannes Stezenbach wrote:
> > On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:  
> > > 
> > > I converted one of the big tables to CSV. At least now it recognized
> > > it as a table. Yet, the table was very badly formated:
> > >   
> > > https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
> > > 
> > > This is how this table should look like:
> > >   https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
> > > 
> > > Also, as this table has merged cells at the legend. I've no idea how
> > > to tell sphinx to do that on csv format.
> > > 
> > > The RST files are on this git tree:
> > >   https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/  
> > 
> > Yeah, seems it can't do merged cells in csv.  Attached patch converts it
> > back to grid table format and fixes the table definition.
> > The html output looks usable, but clearly it is no fun to
> > work with tables in Sphinx.
> > 
> > Sphinx' latex writer can't handle nested tables, though.
> > Python's docutils rst2latex can, but that doesn't help here.
> > rst2pdf also supports it.  But I have doubts such a large
> > table would render OK in pdf without using landscape orientation.
> > I have not tried because I used python3-sphinx but rst2pdf
> > is only availble for Python2 in Debian so it does not integrate
> > with Sphinx.  
> 
> Just a quick idea:
> Perhaps one alternative would be to use Graphviz to render
> the problematic tables, it supports a HTML-like syntax
> and can be embedded in Spinx documents:
> 
> http://www.sphinx-doc.org/en/stable/ext/graphviz.html
> http://www.graphviz.org/content/node-shapes#html
> http://stackoverflow.com/questions/13890568/graphviz-html-nested-tables

That could work, but it is scary... Graphviz is great to generate
diagrams, but it really sucks when one wants to put a graph element
on a specific place, as it loves to reorder elements putting them on
unexpected places.

Btw, 

I converted all docs from our uAPI docbook to rst using pandoc.
It was a brainless conversion, except for a few fixes.

The output is at:
https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/

I added it on the top of my PoC tree at:
https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/  

Besides tables, I noticed some other bad things that needs to be
corrected somehow:

1) Document divisions are not numbered. We need that. It should be
broken into:
- Document divisions - one per documented API:
- V4L2
- Remote Controllers
- DVB
- Media Controller

- Chapters
- Sessions

Everything should be numbered, as, when discussing API improvements,
it is usual the need of pinpoint to an specific chapter and section.

Tables and images should also be numbered, and we need a way to
use references for table/image numbers.

2) Images

Most images didn't popup. We have images on different file formats:
- SVG
- GIF
- PDF
- PNG

3) References

It could be a conversion issue, but there are lots of missing 
references at the documentation.

4) We need to have some way to tell sphinx to not put some things
at the lateral ToC bar. For example, at the V4L2 "Changes" section,
we don't want to have one entry per version at the ToC bar.

Giving that, I suspect that we'll have huge headaches to address
if we use sphinx, as it seems too limited to handle complex
documents. We should try to use some other tool that would give
us better results.


Regards,
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

[PATCH] [media] dw2102: fix unreleased firmware

[Sudip Mukherjee]

On the particular case when the product id is 0x2101 we have requested
for a firmware but after processing it we missed releasing it.

Signed-off-by: Sudip Mukherjee 
---
 drivers/media/usb/dvb-usb/dw2102.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
b/drivers/media/usb/dvb-usb/dw2102.c
index 6d0dd85..1f35f3d 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -1843,6 +1843,9 @@ static int dw2102_load_firmware(struct usb_device *dev,
msleep(100);
kfree(p);
}
+
+   if (le16_to_cpu(dev->descriptor.idProduct) == 0x2101)
+   release_firmware(fw);
return ret;
 }
 
-- 
1.9.1

--
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 4/8] media: Rename is_media_entity_v4l2_io to is_media_entity_v4l2_video_device

[Lad, Prabhakar]

Hi Laurent,

Thanks for the patch.

On Tue, Mar 1, 2016 at 2:57 PM, Laurent Pinchart
 wrote:
> All users of is_media_entity_v4l2_io() (the exynos4-is, omap3isp,
> davince_vpfe and omap4iss drivers) use the function to check whether
> entities are video_device instances, either to ensure they can cast the
> entity to a struct video_device, or to count the number of video nodes
> users.
>
> The purpose of the function is thus to identify whether the media entity
> instance is an instance of the video_device object, not to check whether
> it can perform I/O. Rename it accordingly, we will introduce a more
> specific is_media_entity_v4l2_io() check when needed.
>
> Signed-off-by: Laurent Pinchart 

Acked-by: Lad, Prabhakar 

Cheers,
--Prabhakar Lad
--
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 v3 0/8] i2c mux cleanup and locking update

[Wolfram Sang]

> My offer is going to be this, I'll look after any unforeseen future problems
> caused by this rework, and I can be the i2c-mux maintainer. But if being

Yay, thanks a lot!

> the i2c-mux maintainer turns out to be a huge time-sink, there is no way I
> can stay on in the long run. But I guess that is the same for any maintainer
> (whose job description does not explicitly include being maintainer).

Well, since I became the I2C maintainer in late 2012, i2c-mux was always
low-bandwidth:

$ git log --pretty=oneline v3.2.. -- drivers/i2c/muxes/ drivers/i2c/i2c-mux.c | 
wc -l
72

And your patch series is already bigger than what was accepted in the
last year altogether :) I understand the uncertainty feeling about this
step; however, I truly think it is not much work. It is a niche -
though, one I'd like to have supported by your expertise.

> the mux update. The main commonality of the demux and the preexisting muxes
> seems to be that the name includes "mux" and that it is all about i2c. Agreed?

Yes, and because they are quite different, I wasn't sure if it a) is not
affected at all or b) totally breaks the design. Glad to hear it is a).

Thanks again, looks like we have a roadmap now for getting this series
in \o/

   Wolfram



signature.asc
Description: PGP signature

[PATCH] [media] cx231xx: fix memory leak

[Sudip Mukherjee]

When we returned on error we missed freeing p_current_fw and p_buffer.

Signed-off-by: Sudip Mukherjee 
---
 drivers/media/usb/cx231xx/cx231xx-417.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
b/drivers/media/usb/cx231xx/cx231xx-417.c
index c9320d6..3636d8d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -966,6 +966,7 @@ static int cx231xx_load_firmware(struct cx231xx *dev)
p_buffer = vmalloc(4096);
if (p_buffer == NULL) {
dprintk(2, "FAIL!!!\n");
+   vfree(p_current_fw);
return -1;
}
 
@@ -989,6 +990,8 @@ static int cx231xx_load_firmware(struct cx231xx *dev)
if (retval != 0) {
dev_err(dev->dev,
"%s: Error with mc417_register_write\n", __func__);
+   vfree(p_current_fw);
+   vfree(p_buffer);
return -1;
}
 
@@ -1001,6 +1004,8 @@ static int cx231xx_load_firmware(struct cx231xx *dev)
CX231xx_FIRM_IMAGE_NAME);
dev_err(dev->dev,
"Please fix your hotplug setup, the board will not work 
without firmware loaded!\n");
+   vfree(p_current_fw);
+   vfree(p_buffer);
return -1;
}
 
@@ -1009,6 +1014,8 @@ static int cx231xx_load_firmware(struct cx231xx *dev)
"ERROR: Firmware size mismatch (have %zd, expected 
%d)\n",
firmware->size, CX231xx_FIRM_IMAGE_SIZE);
release_firmware(firmware);
+   vfree(p_current_fw);
+   vfree(p_buffer);
return -1;
}
 
@@ -1016,6 +1023,8 @@ static int cx231xx_load_firmware(struct cx231xx *dev)
dev_err(dev->dev,
"ERROR: Firmware magic mismatch, wrong file?\n");
release_firmware(firmware);
+   vfree(p_current_fw);
+   vfree(p_buffer);
return -1;
}
 
-- 
1.9.1

--
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: [TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes before %pa extension uses

[Nicolas Ferre]

Le 05/03/2016 08:46, Joe Perches a écrit :
> Since commit 3cab1e711297 ("lib/vsprintf: refactor duplicate code
> to special_hex_number()") %pa uses have been ouput with a 0x prefix.
> 
> These 0x prefixes in the formats are unnecessary.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/dma/at_hdmac_regs.h  | 2 +-
>  drivers/media/platform/ti-vpe/cal.c  | 2 +-
>  drivers/nvdimm/pmem.c| 2 +-
>  drivers/rapidio/devices/rio_mport_cdev.c | 4 ++--
>  drivers/rapidio/devices/tsi721.c | 8 
>  5 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index 7f58f06..0474e4a 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -385,7 +385,7 @@ static void vdbg_dump_regs(struct at_dma_chan *atchan) {}
>  static void atc_dump_lli(struct at_dma_chan *atchan, struct at_lli *lli)
>  {
>   dev_crit(chan2dev(>chan_common),
> -  "  desc: s%pad d%pad ctrl0x%x:0x%x l0x%pad\n",
> +  "  desc: s%pad d%pad ctrl0x%x:0x%x l%pad\n",

For this part:
Acked-by: Nicolas Ferre 


>>saddr, >daddr,
>lli->ctrla, lli->ctrlb, >dscr);
>  }
> diff --git a/drivers/media/platform/ti-vpe/cal.c 
> b/drivers/media/platform/ti-vpe/cal.c
> index 82001e6..7dce489 100644
> --- a/drivers/media/platform/ti-vpe/cal.c
> +++ b/drivers/media/platform/ti-vpe/cal.c
> @@ -498,7 +498,7 @@ static inline void cal_runtime_put(struct cal_dev *dev)
>  
>  static void cal_quickdump_regs(struct cal_dev *dev)
>  {
> - cal_info(dev, "CAL Registers @ 0x%pa:\n", >res->start);
> + cal_info(dev, "CAL Registers @ %pa:\n", >res->start);
>   print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 4,
>  (__force const void *)dev->base,
>  resource_size(dev->res), false);
> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
> index 8d0b546..eb619d1 100644
> --- a/drivers/nvdimm/pmem.c
> +++ b/drivers/nvdimm/pmem.c
> @@ -172,7 +172,7 @@ static struct pmem_device *pmem_alloc(struct device *dev,
>  
>   if (!devm_request_mem_region(dev, pmem->phys_addr, pmem->size,
>   dev_name(dev))) {
> - dev_warn(dev, "could not reserve region [0x%pa:0x%zx]\n",
> + dev_warn(dev, "could not reserve region [%pa:0x%zx]\n",
>   >phys_addr, pmem->size);
>   return ERR_PTR(-EBUSY);
>   }
> diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
> b/drivers/rapidio/devices/rio_mport_cdev.c
> index a3369d1..211a67d 100644
> --- a/drivers/rapidio/devices/rio_mport_cdev.c
> +++ b/drivers/rapidio/devices/rio_mport_cdev.c
> @@ -2223,7 +2223,7 @@ static void mport_mm_open(struct vm_area_struct *vma)
>  {
>   struct rio_mport_mapping *map = vma->vm_private_data;
>  
> -rmcd_debug(MMAP, "0x%pad", >phys_addr);
> + rmcd_debug(MMAP, "%pad", >phys_addr);
>   kref_get(>ref);
>  }
>  
> @@ -2231,7 +2231,7 @@ static void mport_mm_close(struct vm_area_struct *vma)
>  {
>   struct rio_mport_mapping *map = vma->vm_private_data;
>  
> -rmcd_debug(MMAP, "0x%pad", >phys_addr);
> + rmcd_debug(MMAP, "%pad", >phys_addr);
>   mutex_lock(>md->buf_mutex);
>   kref_put(>ref, mport_release_mapping);
>   mutex_unlock(>md->buf_mutex);
> diff --git a/drivers/rapidio/devices/tsi721.c 
> b/drivers/rapidio/devices/tsi721.c
> index b5b4556..4c20e99 100644
> --- a/drivers/rapidio/devices/tsi721.c
> +++ b/drivers/rapidio/devices/tsi721.c
> @@ -1101,7 +1101,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
> *mport, dma_addr_t lstart,
>   ibw_start = lstart & ~(ibw_size - 1);
>  
>   tsi_debug(IBW, >pdev->dev,
> - "Direct (RIO_0x%llx -> PCIe_0x%pad), size=0x%x, 
> ibw_start = 0x%llx",
> + "Direct (RIO_0x%llx -> PCIe_%pad), size=0x%x, ibw_start 
> = 0x%llx",
>   rstart, , size, ibw_start);
>  
>   while ((lstart + size) > (ibw_start + ibw_size)) {
> @@ -1120,7 +1120,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
> *mport, dma_addr_t lstart,
>  
>   } else {
>   tsi_debug(IBW, >pdev->dev,
> - "Translated (RIO_0x%llx -> PCIe_0x%pad), size=0x%x",
> + "Translated (RIO_0x%llx -> PCIe_%pad), size=0x%x",
>   rstart, , size);
>  
>   if (!is_power_of_2(size) || size < 0x1000 ||
> @@ -1215,7 +1215,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
> *mport, dma_addr_t lstart,
>   priv->ibwin_cnt--;
>  
>   tsi_debug(IBW, >pdev->dev,
> - "Configured IBWIN%d (RIO_0x%llx -> PCIe_0x%pad), size=0x%llx",
> + "Configured IBWIN%d (RIO_0x%llx -> PCIe_%pad), size=0x%llx",
>   i, ibw_start, _start, ibw_size);
>  
>   return 0;
> @@ -1237,7 +1237,7 @@ static void 

Re: [PATCH 0/2] [media] exynos4-is: Trivial fixes for DT port/endpoint parse logic

[Sylwester Nawrocki]

Hi Javier, Krzysztof,

On 03/05/2016 05:35 AM, Krzysztof Kozlowski wrote:
> 2016-03-05 5:20 GMT+09:00 Javier Martinez Canillas :
>> > Hello,
>> >
>> > This series have two trivial fixes for issues that I noticed while
>> > reading as a reference the driver's functions that parse the graph
>> > port and endpoints nodes.
>> >
>> > It was only compile tested because I don't have access to a Exynos4
>> > hardware to test the DT parsing, but the patches are very simple.
>
> Not directly related, but similar: my previous two patches for missing
> of_node_put [0] are unfortunately still waiting. Although I have
> Exynos4 boards, but I don't have infrastructure/scripts to test it.
> 
> Best regards,
> Krzysztof
> 
> [0] https://patchwork.linuxtv.org/patch/32707/

Thanks for the patches, I've delegated them to myself and I'm going to
review/apply them this week.

--
Regards,
Sylwester
--
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: Build regressions/improvements in v4.5-rc7

[Geert Uytterhoeven]

On Mon, Mar 7, 2016 at 9:55 AM, Geert Uytterhoeven  wrote:
> JFYI, when comparing v4.5-rc7[1] to v4.5-rc6[3], the summaries are:
>   - build errors: +8/-7
  + error: debugfs.c: undefined reference to `clk_round_rate':  =>
.text+0x11b9e0)

arm-randconfig

While looking for more context, I noticed another regression that fell through
the cracks of my script:

arch/arm/kernel/head.o: In function `stext':
(.head.text+0x40): undefined reference to `CONFIG_PHYS_OFFSET'
drivers/built-in.o: In function `v4l2_clk_set_rate':
debugfs.c:(.text+0x11b9e0): undefined reference to `clk_round_rate'

  + error: misc.c: undefined reference to `ftrace_likely_update':  =>
.text+0x714), .text+0x94c), .text+0x3b8), .text+0xc10)

sh-randconfig

arch/sh/boot/compressed/misc.o: In function `lzo1x_decompress_safe':
misc.c:(.text+0x3b8): undefined reference to `ftrace_likely_update'
misc.c:(.text+0x714): undefined reference to `ftrace_likely_update'
misc.c:(.text+0x94c): undefined reference to `ftrace_likely_update'
arch/sh/boot/compressed/misc.o: In function `unlzo.constprop.2':
misc.c:(.text+0xc10): undefined reference to `ftrace_likely_update'

  + /tmp/cc52LvuK.s: Error: can't resolve `_start' {*UND* section} -
`L0^A' {.text section}:  => 41, 403
  + /tmp/ccHfoDA4.s: Error: can't resolve `_start' {*UND* section} -
`L0^A' {.text section}:  => 43
  + /tmp/cch1r0UQ.s: Error: can't resolve `_start' {*UND* section} -
`L0^A' {.text section}:  => 49, 378
  + /tmp/ccoHdFI8.s: Error: can't resolve `_start' {*UND* section} -
`L0^A' {.text section}:  => 43

mips-allnoconfig
bigsur_defconfig
malta_defconfig
cavium_octeon_defconfig

Not really new, but it would be great if the MIPS people could get this
fixed for the final release.

Thanks!

> [1] http://kisskb.ellerman.id.au/kisskb/head/10011/ (all 262 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/9974/ (all 262 configs)

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: Kernel docs: muddying the waters a bit

[Johannes Stezenbach]

On Mon, Mar 07, 2016 at 12:29:08AM +0100, Johannes Stezenbach wrote:
> On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> > 
> > I converted one of the big tables to CSV. At least now it recognized
> > it as a table. Yet, the table was very badly formated:
> > 
> > https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
> > 
> > This is how this table should look like:
> > https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
> > 
> > Also, as this table has merged cells at the legend. I've no idea how
> > to tell sphinx to do that on csv format.
> > 
> > The RST files are on this git tree:
> > https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/
> 
> Yeah, seems it can't do merged cells in csv.  Attached patch converts it
> back to grid table format and fixes the table definition.
> The html output looks usable, but clearly it is no fun to
> work with tables in Sphinx.
> 
> Sphinx' latex writer can't handle nested tables, though.
> Python's docutils rst2latex can, but that doesn't help here.
> rst2pdf also supports it.  But I have doubts such a large
> table would render OK in pdf without using landscape orientation.
> I have not tried because I used python3-sphinx but rst2pdf
> is only availble for Python2 in Debian so it does not integrate
> with Sphinx.

Just a quick idea:
Perhaps one alternative would be to use Graphviz to render
the problematic tables, it supports a HTML-like syntax
and can be embedded in Spinx documents:

http://www.sphinx-doc.org/en/stable/ext/graphviz.html
http://www.graphviz.org/content/node-shapes#html
http://stackoverflow.com/questions/13890568/graphviz-html-nested-tables


Johannes
--
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 v3 0/8] i2c mux cleanup and locking update

[Peter Rosin]

On 2016-03-05 19:29, Wolfram Sang wrote:
> 
>> Perhaps it's one to let sit into at least the next cycle (and get some 
>> testing
>> on those media devices if we can) but, whilst it is fiddly the gains seen in
>> individual drivers (like the example Peter put in response to the V4 series)
>> make it look worthwhile to me.  Also, whilst the invensense part is plain odd
>> in many ways, the case Peter had looks rather more normal.
>>
>> At the end of the day, sometimes fiddly problems need fiddly code. 
>> (says a guy who doesn't have to maintain it!)
>>
>> It certainly helps that Peter has done a thorough job, broken the patches
>> up cleanly and provided clean descriptions of what he is doing.
> 
> Yes, Peter has done a great job so far and the latest results were very
> convincing (fixing the invensense issue and the savings for rtl2832).
> 
> And yes, I am reluctant to maintain this code alone, so my question
> would be:
> 
> Peter, are you interested in becoming the i2c-mux maintainer and look
> after the code even after it was merged? (From "you reviewing patches and
> me picking them up" to "you have your own branch which I pull", we can
> discuss the best workflow.)

My code wouldn't be worth much if I didn't offer to look after it myself. On
the other hand, I am also reluctant to be the go-to person for all things
i2c-mux, as I don't have a clear picture of how much work it's going to be.
My offer is going to be this, I'll look after any unforeseen future problems
caused by this rework, and I can be the i2c-mux maintainer. But if being
the i2c-mux maintainer turns out to be a huge time-sink, there is no way I
can stay on in the long run. But I guess that is the same for any maintainer
(whose job description does not explicitly include being maintainer).

> If that would be the case, I have the same idea like Jonathan: Give it
> another cycle for more review & test and aim for the 4.7 merge window.

Yes, sounds good. One of the reasons for doing things right (or at least
trying to) is to have more people look at the work. *I* think it's good,
but more eyes can't hurt.

> I have to admit that I still haven't done a more thorough review, so I
> can't say if I see a show-stopper in this series. Yet, even if so I am
> positive it can be sorted out. Oh, and we should call for people with
> special experience in locking.
> 
> What do people think?
> 
> Regards,
> 
>Wolfram
> 
> PS: Peter, have you seen my demuxer driver in my for-next branch? I hope
> it won't spoil your design?

I had a brief look, and I can't see anything in the demux that's affected by
the mux update. The main commonality of the demux and the preexisting muxes
seems to be that the name includes "mux" and that it is all about i2c. Agreed?

In short, I see no problems.

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 4/6] [media] st-rc: prevent a endless loop

[Patrice Chotard]

Hi Mauro

On 03/06/2016 02:39 PM, Mauro Carvalho Chehab wrote:

As warned by smatch:
drivers/media/rc/st_rc.c:110 st_rc_rx_interrupt() warn: this loop 
depends on readl() succeeding

as readl() might fail, with likely means some unrecovered error,
let's loop only if it succeeds.

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/rc/st_rc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 1fa0c9d1c508..151bfe2aea55 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -99,7 +99,7 @@ static irqreturn_t st_rc_rx_interrupt(int irq, void *data)
unsigned int symbol, mark = 0;
struct st_rc_device *dev = data;
int last_symbol = 0;
-   u32 status;
+   int status;
DEFINE_IR_RAW_EVENT(ev);
  
  	if (dev->irq_wake)

@@ -107,7 +107,7 @@ static irqreturn_t st_rc_rx_interrupt(int irq, void *data)
  
  	status  = readl(dev->rx_base + IRB_RX_STATUS);
  
-	while (status & (IRB_FIFO_NOT_EMPTY | IRB_OVERFLOW)) {

+   while (status > 0 && (status & (IRB_FIFO_NOT_EMPTY | IRB_OVERFLOW))) {
u32 int_status = readl(dev->rx_base + IRB_RX_INT_STATUS);
if (unlikely(int_status & IRB_RX_OVERRUN_INT)) {
/* discard the entire collection in case of errors!  */


Acked-by: Patrice Chotard 


--
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