<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
hverkuil: <u>mchehab</u>: how do you build the kABI documentation? Ideally just the media kABI?
mchehab: make DOCBOOKS=device-drivers.xml htmldocs 2>&1|grep /media/
<br> my script is actually:
<br> rm Documentation/DocBook/device-drivers.aux.xml Documentation/DocBook/device-dr
<br> ivers.xml
<br> make DOCBOOKS=device-drivers.xml htmldocs 2>&1|grep /media/
hverkuil: thanks!
mchehab: please notice that you should have built before the media API docbook, as otherwise the makefile may fail
<br> because of the lack of some media_api targets
<br> <u>pinchartl</u>: any news with regards to MC patch series review?
pinchartl: you can also make DOCBOOKS=media_api.xml htmldocs
<br> <u>mchehab</u>: ongoing, working on it today (along with patchwork)
mchehab: ok
pinchartl: <u>hverkuil</u>: there will be lots of details to sort out with the request API
<br> the more I work on it the more it gets complex in its interactions with the rest of the V4L2 API
<br> for instance
<br> parameters that are not specified in a request should use their current value, right ?
hverkuil: <u>pinchartl</u>: that's correct, unless they are changed as a side-effect of setting another parameter in the request.
pinchartl: <u>hverkuil</u>: now the question is
<br> the current value at what time ?
<br> when the request is queued ?
<br> or ealier ?
<br> the reason I'm asking
<br> is that if I set the format on a pad of a subdev for a request
<br> I need to define the format of all other pads at the same time in the same request
<br> it would make sense to latch those formats when setting the subdev pad format
hverkuil: as I defined it it is the value at the time the request is applied by the driver. Remember that it was designed around the control framework and that's how the control framework behaves.
<br> I am not sure what you mean with "to latch those formats when setting the subdev pad format"
pinchartl: subdev pad formats depend on one another
<br> the source pad format typically depends on the sink pad format
<br> and format mangling is done at s_fmt time
<br> let's assume I have a scaler subdev
<br> it can't change the pixel code
<br> all it can do is scale the image
<br> the device is configured with YUYV 1024x768 on the sink and source pads
<br> if I try to set the source pad to UYVY 640x480
<br> the driver will return YUYV 640x480
<br> and that's what will be stored in the request
<br> what if I then change the active format on the sink (and thus source) pads to UYVY and queue the request ?
<br> it would make sense to copy the active value of all pad formats in the request when the user sets the format on a pad
<br> and proceed with that when queuing the request
hverkuil: I have no objection against that. The question is what is easiest for the driver. Allowing complex format changes midstream is a nightmare to implement, and I feel that the driver implementation should be kept as simple as possible.
<br> If that means that the application has to do things in a certain order, or always provide all formats in the request, then I am fine with that as well.
<br> I think you are best placed to decide this since you're gaining some experience with how it works.
shuah: mchehab, javier__ : have you tested the MC next gen work with LOCK debug enabled? I am seeing problems when I do that
javier__: <u>shuah</u>: which Kconfig symbols exactly? I tested using the default omap2plus_defconfig and exynos_defconfig configs since my test platforms are an OMAP3 board with a tvp5151 video encoder and an Exynos Chromebook with a UVC camera
pinchartl: <u>hverkuil</u>: I'll propose something then :-)
<br> (120 patches to go in patchwork)
shuah: <u>javier__</u>: I will share my config with me in a little bit. You will see these problems when you do device removal
broonie: Device removal might be the issue here, tends to be hard to do normally on embedded systems :)
shuah: no I am testing it on a laptop - so embedded isn't the issue
<br> <u>javier__</u>: I have CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_LOCK_ALLOC, CONFIG_PROVE_LOCKING, CONFIG_DEBUG_LOCKDEP enabled
<br> I will send you the dmesg in email in just a bit
mchehab: <u>shuah</u>: probably I didn't enable any of those
shuah: I have gotten in the habit of doing that after the au0828 videlbuf to vb2 port
mchehab: neither with or without the MC patches
shuah: ah ok - I know for sure this new warning is from MC next gen stuff - I didn't see any with MC - I have the same config on both
mchehab: sometimes, the spinlock detection needs to be feed with additional info to do the right thing
<br> (e. g. creating a spinlock group)
<br> anyway, as I said, I didn't check
shuah: ah ok - maybe what I am seeing is okay - I just didn't want to walk away from it without understanding fully - Will send dmesg in a just a bit
<br> I can test and debug - agenda for this week :)
mchehab: good! thanks for that!
broonie: <u>shuah</u>: I mean if javier__ is testing on embedded systems there's no option to physically unplug the capture devices usually so you're testing something he most likely hasn't.
<br> Or at least is likely to have tested less.
shuah: right I understand what you are saying. Our test setup is different
javier__: <u>shuah</u>: sorry I was having lunch
shuah: no problem - you should see dmesg in your inbox now
javier__: <u>shuah</u>: broonie is correct, in both systems there is no way to unplog the capture dev. Even for the Exynos Chromebooks where the camera is a USB UVC device, the camera is hardwired
milliz: hi
broonie: <u>javier__</u>: Hacksaw :)
javier__: <u>broonie</u>: haha
milliz: in hav prob my ting
<br> dvb-s2
myself: in a lot of cases you can force a USB controller to re-init, but that's all sorts of dirty
milliz: pctv 461e
<br> on hd transponders
<br> green screen n shite pic on certain mux
<br> am using vdpau w/ decreaseed cpu usage but
<br> still not good enough , not pleased w/ driver
<br> or demod
<br> c-band mux on pctv 461e
<br> tried tvheadond vdr, even windows software mp and argus... same hd mux same result
<br> this is off a 3 metre mesh dish with 76 % quality signal
<br> absolute shite
<br> clearly when they made this stick they ignored the cband side of dvbs
javier__: <u>shuah</u>: so from your logs, it seems the softlockup happens when the mdev->lock spinlock is held in media_device_unregister_entity()
shuah: right - after device removal during usb disconnect
javier__: nod
pinchartl: <u>posciak</u>: ping
<br> (I assume you're asleep)
<br> regarding UVC 1.5
<br> how much work do you think it would be to have basic UVC 1.5 support without H.264 ?
<br> just enough to get the device up and running with YUV and MJPEG
<br> <u>prabhakarlad</u>: do you still maintain the staging davinci_vpfe driver ?
<br> dinner time, bbiab
<br> <u>mchehab</u>: down to 86 patches, I'll continue after dinner
<br> <u>hverkuil</u>: what's the status of the the "y2038 conversion for subsystem" patch series ? superseded by our decision to create a new v4l2_buffer structure ?
<br> <u>mchehab</u>: down to 37 patches. 8 of these are part of the current MC rework, and another 14 are for a libv4l plugin
<br> that's as much as I can do for now
<br> there's some omap3 isp and uvc patches that require quite a bit of work on my side and I won't have time for that in the near future