Re: Hauppauge WinTV-HVR2205 driver feedback

2015-10-11 Thread Tycho Lürsen



Op 11-10-15 om 08:18 schreef Richard Tresidder:

Hi Again
  Yep that fixed pulling in the saa7164: si2168 frontends:

[ 6778.591548] i2c i2c-15: Added multiplexed i2c bus 16
[ 6778.591556] si2168 15-0064: Silicon Labs Si2168 successfully attached
[ 6778.596252] si2157 13-0060: Silicon Labs Si2147/2148/2157/2158
successfully attached
[ 6778.597229] DVB: registering new adapter (saa7164)
YAY!!

Bottoms up!


What a painful process... first time I built the kernel from the rpm
source I must have stuffed something up and the resultant installed
rpm didn't have the module turned on.. aaagggh...
Trying to rebuild the srpm again after tweaking the .config file and
copying it around to the various locations again just didn't work..
Eventually gave up and had to rip it all out and start afresh..
It's not that hard once you get the hang of it. I had to recompile 
anyway, as I need saa716x, dvbloopback and backported drivers for DVBSky 
T982, plus I need more then 8 dvb adapters. Semi-automated this of course:

https://github.com/bas-t/centos7-kernel


Well spotted on that one.. What a pain that the call to the i2c mux
create didn't result in a error :/

Now I just need to shutoff kernel updates..
Really need to push this up into the centos config.. I've noted that
it has been turned back on in other releases..
Will submit a bug.

Excellent idea. But as stated, I'll have to recompile anyway...


Regards
   Richard Tresidder

On 05/10/15 20:45, Tycho Lürsen wrote:

Hi, not sure if this is related.
I had to recompile the centos7 stock kernel with:
CONFIG_I2C_MUX=m

It was not enabled in the kernel config.

Op 04-10-15 om 06:55 schreef Richard Tresidder:

Sorry If I've posted this to the wrong section my first attempt..

Hi
   I'm attempting to get an HVR2205 up and going.
CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge
WinTV-HVR2205 [card=13,autodetected]
Distribution is CentOS7 so I've pulled the v4l from media_build.git
Had to change a couple of things..  and another macro issue
regarding clamp() ..
Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was
failing..
kept getting:  kernel: modprobe: page allocation failure: order:10,
mode:0x10c0d0
Have plenty of RAM free so surprised about that one.. tried some of
the tricks re increasing the vm.min_free_kbytes etc..

Any way I modified the routine to only allocate a single chunk
buffer based on dstsize and tweaked the chunk handling code..
seemed to fix that one.. fw downloaded and seemed to boot ok..

Next I'm running into a problem with the saa7164_dvb_register()
stage...

saa7164[1]: Hauppauge eeprom: model=151609
saa7164_dvb_register() Frontend/I2C initialization failed
saa7164_initdev() Failed to register dvb adapters on porta

I added some extra debug and identified that
client_demod->dev.driver is null..

However I'm now stuck as to what to tackle next..

I can provide more info, just didn't want to spam the list for my
first email..

Regards
   Richard Tresidder
--
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


Re: Elgato Eye TV Deluxe V2 supported?

2015-10-11 Thread Another Sillyname
I realise this is from over a year ago but I ended up putting it to
one side till the kernel 'caught up' as it were.

Looking at github/torvalds/linux/tree/master/drivers/media/dvb-frontends
it looks like the as102 support is now in mainline and indeed looking
at staging there's no reference at all to any as102 devices.

I've just installed FC22 Kernel 4-1-10-200 x86_64 onto a box and
installed the required firmware files into /lib/firmware in the hope
the device would now workunfortunately plugging it in gives me
exactly the same as early last year.no firmware load even though
dmesg sees the device installed.

Am I still stuck with potentially having to compile a custom kernel to
support this device under Fedora (which isn't an option due to SELinux
issues it would present elsewhere).

Thanks in advance.

On 2 May 2014 at 14:52, Another Sillyname  wrote:
> OK, I realise I should be able to work this outbut I'm stuck and
> no matter how much I read I've developed a mental block (think of it
> as the computing version of writers block).
>
> I use Fedora as my primary OS, currently Fedora 20 latest kernel 3.13
>
> I need to keep using this kernel as I use SELinux for a couple of
> things on my server and compiling a vanilla kernel and patching
> SELinux in is just way too messy
>
> As the V4L-DVB Media_Tree is NOT included in the kernel-devel version
> of the Fedora kernel it requires a complete kernel compile to download
> the required media tree, however I can't then get the V4L-DVB media
> tree from git to patch against the Fedora (uncompiled) kernel prior to
> compilation, I've installed all the tools required (I have built a few
> kernels before when I needed to) but I've just hit a mental wall..
>
> Help!!
>
>
>
> On 25 April 2014 20:06, Another Sillyname  wrote:
>> OK, I'm not a coder these days but I'll look and see if I can work it out.
>>
>> Regards and have a good weekend.
>>
>> Tony
>>
>> On 25 April 2014 19:54, Devin Heitmueller  
>> wrote:
 Is the as102 tree ever likely to go mainline?
>>>
>>> The only reason it's in staging is because it doesn't meet the coding
>>> standards (i.e. whitespace, variable naming, etc).  Somebody needs to
>>> come along and expend the energy to satisfy the whitespace gods.
>>>
>>> Seems like a fantastically stupid reason to keep a working driver out
>>> of the mainline, but that's just my opinion.
>>>
>>> Devin
>>>
>>> --
>>> Devin J. Heitmueller - Kernel Labs
>>> http://www.kernellabs.com
--
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-core.c:undefined reference to `v4l2_get_timestamp'

2015-10-11 Thread Fengguang Wu
Hi Florian,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4a06c8ac2fb3ef484579ce44f9b809bd310fad48
commit: e831cd251fb91d6c25352d322743db0d17ea11dd [media] add raw video stream 
support for Samsung SUR40
date:   6 months ago
config: x86_64-randconfig-n0-10111553 (attached as .config)
reproduce:
git checkout e831cd251fb91d6c25352d322743db0d17ea11dd
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `sur40_disconnect':
   sur40.c:(.text+0x241ed1): undefined reference to `video_unregister_device'
   sur40.c:(.text+0x241ee2): undefined reference to `v4l2_device_unregister'
   drivers/built-in.o: In function `sur40_process_video':
   sur40.c:(.text+0x24236d): undefined reference to `v4l2_get_timestamp'
   drivers/built-in.o: In function `sur40_vidioc_querycap':
   sur40.c:(.text+0x2429b3): undefined reference to `video_devdata'
   drivers/built-in.o: In function `sur40_probe':
   sur40.c:(.text+0x242e52): undefined reference to `v4l2_device_register'
   sur40.c:(.text+0x242efd): undefined reference to `v4l2_device_unregister'
   sur40.c:(.text+0x243003): undefined reference to `video_device_release_empty'
   sur40.c:(.text+0x24304d): undefined reference to `__video_register_device'
   sur40.c:(.text+0x24309d): undefined reference to `video_unregister_device'
   drivers/built-in.o: In function `vb2_fop_mmap':
>> (.text+0x250d65): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_expbuf':
   (.text+0x250da6): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_streamoff':
   (.text+0x250e26): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_streamon':
   (.text+0x250ea6): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_dqbuf':
   (.text+0x251cb6): undefined reference to `video_devdata'
   drivers/built-in.o:(.text+0x251fc5): more undefined references to 
`video_devdata' follow
   drivers/built-in.o: In function `vb2_thread':
>> videobuf2-core.c:(.text+0x25348d): undefined reference to 
>> `v4l2_get_timestamp'
   drivers/built-in.o: In function `vb2_ioctl_qbuf':
   (.text+0x2535a6): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_prepare_buf':
   (.text+0x2537a6): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_create_bufs':
   (.text+0x253fac): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_reqbufs':
   (.text+0x25465c): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_poll':
   (.text+0x254c5d): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_poll':
>> (.text+0x254ee3): undefined reference to `v4l2_event_pending'
   drivers/built-in.o: In function `vb2_fop_poll':
   (.text+0x255240): undefined reference to `video_devdata'
   drivers/built-in.o: In function `__vb2_perform_fileio':
   videobuf2-core.c:(.text+0x255ec1): undefined reference to 
`v4l2_get_timestamp'
   drivers/built-in.o: In function `vb2_fop_read':
   (.text+0x2560f7): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_fop_write':
   (.text+0x2562a7): undefined reference to `video_devdata'
   drivers/built-in.o: In function `_vb2_fop_release':
   (.text+0x25650c): undefined reference to `video_devdata'
   drivers/built-in.o: In function `_vb2_fop_release':
>> (.text+0x256566): undefined reference to `v4l2_fh_release'
   drivers/built-in.o: In function `vb2_fop_release':
   (.text+0x256605): undefined reference to `video_devdata'
   drivers/built-in.o:(.rodata+0x26320): undefined reference to `video_ioctl2'
   drivers/built-in.o:(.rodata+0x26340): undefined reference to `v4l2_fh_open'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


drivers/media/dvb-core/dvbdev.h:157:18: error: too many arguments to function '__a'

2015-10-11 Thread Fengguang Wu
Hi Kozlov,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4a06c8ac2fb3ef484579ce44f9b809bd310fad48
commit: 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e [media] netup_unidvb: NetUP 
Universal DVB-S/S2/T/T2/C PCI-E card driver
date:   9 weeks ago
config: x86_64-randconfig-b0-10111047 (attached as .config)
reproduce:
git checkout 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from 
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:34:0:
   drivers/media/dvb-frontends/horus3a.h:51:13: warning: 'struct 
cxd2820r_config' declared inside parameter list
 struct i2c_adapter *i2c)
^
   drivers/media/dvb-frontends/horus3a.h:51:13: warning: its scope is only this 
definition or declaration, which is probably not what you want
   In file included from 
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:36:0:
   drivers/media/dvb-frontends/lnbh25.h:46:15: error: unknown type name 
'dvb_frontend'
static inline dvb_frontend *lnbh25_attach(
  ^
   In file included from include/media/videobuf2-dvb.h:4:0,
from drivers/media/pci/netup_unidvb/netup_unidvb.h:26,
from drivers/media/pci/netup_unidvb/netup_unidvb_core.c:32:
   drivers/media/pci/netup_unidvb/netup_unidvb_core.c: In function 
'netup_unidvb_dvb_init':
   drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:34: warning: passing 
argument 1 of '__a' from incompatible pointer type 
[-Wincompatible-pointer-types]
 if (!dvb_attach(horus3a_attach, fe0->dvb.frontend,
 ^
   drivers/media/dvb-core/dvbdev.h:157:22: note: in definition of macro 
'dvb_attach'
  __r = (void *) __a(ARGS); \
 ^
   drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:34: note: expected 
'const struct cxd2820r_config *' but argument is of type 'struct dvb_frontend *'
 if (!dvb_attach(horus3a_attach, fe0->dvb.frontend,
 ^
   drivers/media/dvb-core/dvbdev.h:157:22: note: in definition of macro 
'dvb_attach'
  __r = (void *) __a(ARGS); \
 ^
   drivers/media/pci/netup_unidvb/netup_unidvb_core.c:418:4: warning: passing 
argument 2 of '__a' from incompatible pointer type 
[-Wincompatible-pointer-types]
   _conf, >i2c[num].adap)) {
   ^
   drivers/media/dvb-core/dvbdev.h:157:22: note: in definition of macro 
'dvb_attach'
  __r = (void *) __a(ARGS); \
 ^
   drivers/media/pci/netup_unidvb/netup_unidvb_core.c:418:4: note: expected 
'struct i2c_adapter *' but argument is of type 'struct horus3a_config *'
   _conf, >i2c[num].adap)) {
   ^
   drivers/media/dvb-core/dvbdev.h:157:22: note: in definition of macro 
'dvb_attach'
  __r = (void *) __a(ARGS); \
 ^
>> drivers/media/dvb-core/dvbdev.h:157:18: error: too many arguments to 
>> function '__a'
  __r = (void *) __a(ARGS); \
 ^
   drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:7: note: in expansion 
of macro 'dvb_attach'
 if (!dvb_attach(horus3a_attach, fe0->dvb.frontend,
  ^

vim +/__a +157 drivers/media/dvb-core/dvbdev.h

16ef8def drivers/media/dvb/dvb-core/dvbdev.h Arnd Bergmann 2010-04-27  
141  extern long dvb_generic_ioctl (struct file *file,
^1da177e drivers/media/dvb/dvb-core/dvbdev.h Linus Torvalds2005-04-16  
142unsigned int cmd, unsigned long arg);
^1da177e drivers/media/dvb/dvb-core/dvbdev.h Linus Torvalds2005-04-16  
143  
^1da177e drivers/media/dvb/dvb-core/dvbdev.h Linus Torvalds2005-04-16  
144  /* we don't mess with video_usercopy() any more,
^1da177e drivers/media/dvb/dvb-core/dvbdev.h Linus Torvalds2005-04-16  
145  we simply define out own dvb_usercopy(), which will hopefully become
^1da177e drivers/media/dvb/dvb-core/dvbdev.h Linus Torvalds2005-04-16  
146  generic_usercopy()  someday... */
^1da177e drivers/media/dvb/dvb-core/dvbdev.h Linus Torvalds2005-04-16  
147  
16ef8def drivers/media/dvb/dvb-core/dvbdev.h Arnd Bergmann 2010-04-27  
148  extern int dvb_usercopy(struct file *file, unsigned int cmd, unsigned long 
arg,
16ef8def drivers/media/dvb/dvb-core/dvbdev.h Arnd Bergmann 2010-04-27  
149  int (*func)(struct file *file, unsigned int cmd, 
void *arg));
^1da177e drivers/media/dvb/dvb-core/dvbdev.h Linus Torvalds2005-04-16  
150  
d9955060 drivers/media/dvb/dvb-core/dvbdev.h Andrew de Quincey 2006-08-08  
151  /** generic DVB attach function. */
149ef72d drivers/media/dvb/dvb-core/dvbdev.h Mauro Carvalho Chehab 2008-04-29  
152  #ifdef CONFIG_MEDIA_ATTACH
d9955060 drivers/media/dvb/dvb-core/dvbdev.h Andrew de Quincey 2006-08-08  
153  #define 

Re: Hauppauge WinTV-HVR2205 driver feedback

2015-10-11 Thread Richard Tresidder

Hi Again
  Yep that fixed pulling in the saa7164: si2168 frontends:

[ 6778.591548] i2c i2c-15: Added multiplexed i2c bus 16
[ 6778.591556] si2168 15-0064: Silicon Labs Si2168 successfully attached
[ 6778.596252] si2157 13-0060: Silicon Labs Si2147/2148/2157/2158 
successfully attached

[ 6778.597229] DVB: registering new adapter (saa7164)
YAY!!

What a painful process... first time I built the kernel from the rpm 
source I must have stuffed something up and the resultant installed rpm 
didn't have the module turned on.. aaagggh...
Trying to rebuild the srpm again after tweaking the .config file and 
copying it around to the various locations again just didn't work.. 
Eventually gave up and had to rip it all out and start afresh..


Well spotted on that one.. What a pain that the call to the i2c mux 
create didn't result in a error :/


Now I just need to shutoff kernel updates..
Really need to push this up into the centos config.. I've noted that it 
has been turned back on in other releases..

Will submit a bug.

Regards
   Richard Tresidder

On 05/10/15 20:45, Tycho Lürsen wrote:

Hi, not sure if this is related.
I had to recompile the centos7 stock kernel with:
CONFIG_I2C_MUX=m

It was not enabled in the kernel config.

Op 04-10-15 om 06:55 schreef Richard Tresidder:

Sorry If I've posted this to the wrong section my first attempt..

Hi
   I'm attempting to get an HVR2205 up and going.
CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 
[card=13,autodetected]

Distribution is CentOS7 so I've pulled the v4l from media_build.git
Had to change a couple of things..  and another macro issue regarding 
clamp() ..
Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was 
failing..
kept getting:  kernel: modprobe: page allocation failure: order:10, 
mode:0x10c0d0
Have plenty of RAM free so surprised about that one.. tried some of 
the tricks re increasing the vm.min_free_kbytes etc..


Any way I modified the routine to only allocate a single chunk buffer 
based on dstsize and tweaked the chunk handling code..

seemed to fix that one.. fw downloaded and seemed to boot ok..

Next I'm running into a problem with the saa7164_dvb_register() stage...

saa7164[1]: Hauppauge eeprom: model=151609
saa7164_dvb_register() Frontend/I2C initialization failed
saa7164_initdev() Failed to register dvb adapters on porta

I added some extra debug and identified that client_demod->dev.driver 
is null..


However I'm now stuck as to what to tackle next..

I can provide more info, just didn't want to spam the list for my 
first email..


Regards
   Richard Tresidder
--
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


Re: [PATCHv5 10/13] hackrf: add support for transmitter

2015-10-11 Thread Antti Palosaari

Moikka!
IMHO it is false positive. Variable which is defined on line 777 is used 
just few lines later on line 782 as can be seen easily. I think it is 
because option CONFIG_DYNAMIC_DEBUG is not set => dev_dbg_ratelimited() 
macro is likely just NOP and gives that warning. Maybe some more logic 
to is needed in order to avoid that kind of warnings.


regards
Antti

On 10/11/2015 03:55 AM, kbuild test robot wrote:

Hi Antti,

[auto build test WARNING on linuxtv-media/master -- if it's inappropriate base, 
please ignore]

config: i386-randconfig-i1-201541 (attached as .config)
reproduce:
 # save the attached .config to linux build tree
 make ARCH=i386

All warnings (new ones prefixed by >>):

drivers/media/usb/hackrf/hackrf.c: In function 'hackrf_buf_queue':

drivers/media/usb/hackrf/hackrf.c:777:24: warning: unused variable 'intf' 
[-Wunused-variable]

  struct usb_interface *intf = dev->intf;
^

vim +/intf +777 drivers/media/usb/hackrf/hackrf.c

761 
762 /* Need at least 8 buffers */
763 if (vq->num_buffers + *nbuffers < 8)
764 *nbuffers = 8 - vq->num_buffers;
765 *nplanes = 1;
766 sizes[0] = PAGE_ALIGN(dev->buffersize);
767 
768 dev_dbg(dev->dev, "nbuffers=%d sizes[0]=%d\n", *nbuffers, 
sizes[0]);
769 return 0;
770 }
771 
772 static void hackrf_buf_queue(struct vb2_buffer *vb)
773 {
774 struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
775 struct vb2_queue *vq = vb->vb2_queue;
776 struct hackrf_dev *dev = vb2_get_drv_priv(vq);
  > 777  struct usb_interface *intf = dev->intf;
778 struct hackrf_buffer *buffer = container_of(vbuf, struct 
hackrf_buffer, vb);
779 struct list_head *buffer_list;
780 unsigned long flags;
781 
782 dev_dbg_ratelimited(>dev, "\n");
783 
784 if (vq->type == V4L2_BUF_TYPE_SDR_CAPTURE)
785 buffer_list = >rx_buffer_list;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation



--
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] mt9t001: constify v4l2_subdev_internal_ops structure

2015-10-11 Thread Julia Lawall
This v4l2_subdev_internal_ops structure is never modified.  All other
v4l2_subdev_internal_ops structures are declared as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/media/i2c/mt9t001.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/mt9t001.c b/drivers/media/i2c/mt9t001.c
index 8ae99f7..4383a5d 100644
--- a/drivers/media/i2c/mt9t001.c
+++ b/drivers/media/i2c/mt9t001.c
@@ -834,7 +834,7 @@ static struct v4l2_subdev_ops mt9t001_subdev_ops = {
.pad = _subdev_pad_ops,
 };
 
-static struct v4l2_subdev_internal_ops mt9t001_subdev_internal_ops = {
+static const struct v4l2_subdev_internal_ops mt9t001_subdev_internal_ops = {
.registered = mt9t001_registered,
.open = mt9t001_open,
.close = mt9t001_close,

--
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 v8 32/55] [media] media: use macros to check for V4L2 subdev entities

2015-10-11 Thread Sakari Ailus
Hi Mauro,

On Sun, Aug 30, 2015 at 12:06:43AM -0300, Mauro Carvalho Chehab wrote:
> Instead of relying on media subtype, use the new macros to detect
> if an entity is a subdev or an A/V DMA entity.
> 
> Please note that most drivers assume that there's just AV_DMA or
> V4L2 subdevs. This is not true anymore, as we've added MC support
> for DVB, and there are plans to add support for ALSA and FB/DRM
> too.
> 
> Ok, on the current pipelines supported by those drivers, just V4L
> stuff are there, but, assuming that some day a pipeline that also
> works with other subsystems will ever added, it is better to add
> explicit checks for the AV_DMA stuff.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> diff --git a/drivers/media/platform/exynos4-is/common.c 
> b/drivers/media/platform/exynos4-is/common.c
> index 0eb34ecb8ee4..8c9a29e0e294 100644
> --- a/drivers/media/platform/exynos4-is/common.c
> +++ b/drivers/media/platform/exynos4-is/common.c
> @@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct 
> media_entity *entity)
>   while (pad->flags & MEDIA_PAD_FL_SINK) {
>   /* source pad */
>   pad = media_entity_remote_pad(pad);
> - if (pad == NULL ||
> - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
>   break;
>  
>   sd = media_entity_to_v4l2_subdev(pad->entity);
> diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
> b/drivers/media/platform/exynos4-is/fimc-capture.c
> index 0627a93b2f3b..e9810fee4c30 100644
> --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> @@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev *fimc)
>   }
>   }
>  
> - if (src_pad == NULL ||
> - media_entity_type(src_pad->entity) != 
> MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!src_pad || !is_media_entity_v4l2_subdev(src_pad->entity))
>   break;
>  
>   /* Don't call FIMC subdev operation to avoid nested locking */
> @@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity *entity,
>   struct fimc_vid_cap *vc = >vid_cap;
>   struct v4l2_subdev *sensor;
>  
> - if (media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!is_media_entity_v4l2_subdev(remote->entity))
>   return -EINVAL;
>  
>   if (WARN_ON(fimc == NULL))
> diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c 
> b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> index 3d9ccbf5f10f..5fbaf5e39903 100644
> --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> @@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct fimc_isp 
> *isp)
>  
>   /* Retrieve format at the source pad */
>   pad = media_entity_remote_pad(pad);
> - if (pad == NULL ||
> - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
>   break;
>  
>   sd = media_entity_to_v4l2_subdev(pad->entity);
> diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
> b/drivers/media/platform/exynos4-is/fimc-lite.c
> index b2607da4ad14..c2327147b360 100644
> --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> @@ -814,8 +814,7 @@ static int fimc_pipeline_validate(struct fimc_lite *fimc)
>   }
>   /* Retrieve format at the source pad */
>   pad = media_entity_remote_pad(pad);
> - if (pad == NULL ||
> - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
>   break;
>  
>   sd = media_entity_to_v4l2_subdev(pad->entity);
> @@ -988,7 +987,6 @@ static int fimc_lite_link_setup(struct media_entity 
> *entity,
>  {
>   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>   struct fimc_lite *fimc = v4l2_get_subdevdata(sd);
> - unsigned int remote_ent_type = media_entity_type(remote->entity);
>   int ret = 0;
>  
>   if (WARN_ON(fimc == NULL))
> @@ -1000,7 +998,7 @@ static int fimc_lite_link_setup(struct media_entity 
> *entity,
>  
>   switch (local->index) {
>   case FLITE_SD_PAD_SINK:
> - if (remote_ent_type != MEDIA_ENT_T_V4L2_SUBDEV) {
> + if (!is_media_entity_v4l2_subdev(remote->entity)) {
>   ret = -EINVAL;
>   break;
>   }
> @@ -1018,7 +1016,7 @@ static int fimc_lite_link_setup(struct media_entity 
> *entity,
>   case FLITE_SD_PAD_SOURCE_DMA:
>   if (!(flags & 

Re: How to fix DocBook parsers for private fields inside #ifdefs

2015-10-11 Thread Jonathan Corbet
On Mon, 5 Oct 2015 09:03:48 -0300
Mauro Carvalho Chehab  wrote:

> Patch enclosed.

...and applied, thanks!

jon
--
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 v8 32/55] [media] media: use macros to check for V4L2 subdev entities

2015-10-11 Thread Mauro Carvalho Chehab
Em Mon, 12 Oct 2015 00:07:52 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Sun, Aug 30, 2015 at 12:06:43AM -0300, Mauro Carvalho Chehab wrote:
> > Instead of relying on media subtype, use the new macros to detect
> > if an entity is a subdev or an A/V DMA entity.
> > 
> > Please note that most drivers assume that there's just AV_DMA or
> > V4L2 subdevs. This is not true anymore, as we've added MC support
> > for DVB, and there are plans to add support for ALSA and FB/DRM
> > too.
> > 
> > Ok, on the current pipelines supported by those drivers, just V4L
> > stuff are there, but, assuming that some day a pipeline that also
> > works with other subsystems will ever added, it is better to add
> > explicit checks for the AV_DMA stuff.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > 
> > diff --git a/drivers/media/platform/exynos4-is/common.c 
> > b/drivers/media/platform/exynos4-is/common.c
> > index 0eb34ecb8ee4..8c9a29e0e294 100644
> > --- a/drivers/media/platform/exynos4-is/common.c
> > +++ b/drivers/media/platform/exynos4-is/common.c
> > @@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct 
> > media_entity *entity)
> > while (pad->flags & MEDIA_PAD_FL_SINK) {
> > /* source pad */
> > pad = media_entity_remote_pad(pad);
> > -   if (pad == NULL ||
> > -   media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > break;
> >  
> > sd = media_entity_to_v4l2_subdev(pad->entity);
> > diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
> > b/drivers/media/platform/exynos4-is/fimc-capture.c
> > index 0627a93b2f3b..e9810fee4c30 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> > @@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev 
> > *fimc)
> > }
> > }
> >  
> > -   if (src_pad == NULL ||
> > -   media_entity_type(src_pad->entity) != 
> > MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!src_pad || !is_media_entity_v4l2_subdev(src_pad->entity))
> > break;
> >  
> > /* Don't call FIMC subdev operation to avoid nested locking */
> > @@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity 
> > *entity,
> > struct fimc_vid_cap *vc = >vid_cap;
> > struct v4l2_subdev *sensor;
> >  
> > -   if (media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!is_media_entity_v4l2_subdev(remote->entity))
> > return -EINVAL;
> >  
> > if (WARN_ON(fimc == NULL))
> > diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c 
> > b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > index 3d9ccbf5f10f..5fbaf5e39903 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > @@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct fimc_isp 
> > *isp)
> >  
> > /* Retrieve format at the source pad */
> > pad = media_entity_remote_pad(pad);
> > -   if (pad == NULL ||
> > -   media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > break;
> >  
> > sd = media_entity_to_v4l2_subdev(pad->entity);
> > diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
> > b/drivers/media/platform/exynos4-is/fimc-lite.c
> > index b2607da4ad14..c2327147b360 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> > @@ -814,8 +814,7 @@ static int fimc_pipeline_validate(struct fimc_lite 
> > *fimc)
> > }
> > /* Retrieve format at the source pad */
> > pad = media_entity_remote_pad(pad);
> > -   if (pad == NULL ||
> > -   media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > break;
> >  
> > sd = media_entity_to_v4l2_subdev(pad->entity);
> > @@ -988,7 +987,6 @@ static int fimc_lite_link_setup(struct media_entity 
> > *entity,
> >  {
> > struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > struct fimc_lite *fimc = v4l2_get_subdevdata(sd);
> > -   unsigned int remote_ent_type = media_entity_type(remote->entity);
> > int ret = 0;
> >  
> > if (WARN_ON(fimc == NULL))
> > @@ -1000,7 +998,7 @@ static int fimc_lite_link_setup(struct media_entity 
> > *entity,
> >  
> > switch (local->index) {
> > case FLITE_SD_PAD_SINK:
> > -   if (remote_ent_type != MEDIA_ENT_T_V4L2_SUBDEV) {
> > +   if (!is_media_entity_v4l2_subdev(remote->entity)) {
> > ret = -EINVAL;
> > 

cron job: media_tree daily build: ERRORS

2015-10-11 Thread 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:   Mon Oct 12 04:00:16 CEST 2015
git branch: test
git hash:   efe98010b80ec4516b2779e1b4e4a8ce16bf89fe
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:4.0.0-3.slh.1-amd64

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.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: 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-rc1-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: 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-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: ERRORS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

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