<!-- 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>
***: paulk-leonov has quit IRC (*.net *.split)
<br> z3ntu has quit IRC (*.net *.split)
<br> lucaceresoli has quit IRC (Ping timeout: 244 seconds)
<br> ntrrgc has quit IRC (Ping timeout: 252 seconds)
paulk-leonov: <u>jernej</u>: I am definitely interested yes :)
***: snawrocki has quit IRC (Ping timeout: 246 seconds)
sailus: <u>mchehab</u>: Bom dia!
<br> When do you think we'd remove SoC camera?
<br> I was just wondering whether the MAINTAINERS entry is worth fixing.
***: nst_ has quit IRC (Quit: WeeChat 2.3)
hverkuil: <u>ezequielg</u>: I've been working on m2m-deinterlacer on my pandaboard. It suffers from a severe case of bit rot, but I got it to pass v4l2-compliance. Unfortunately, the deinterlacer is producing buffers with all zeroes :-(
<br> The patch is here, in case you are interested: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=v4l2-fh
<br> <u>pH5</u>: ping
pH5: <u>hverkuil</u>: pong
hverkuil: <u>pH5</u>: is the mx2_emmaprp driver specific to i.MX2, or do later SoCs have that same block?
<br> I suspect it is imx2 specific, but it would be great if you can confirm that.
mchehab: <u>sailus</u>: I proposed a Kernel version for its removal on my patch
<br> I would give up to ~feb next year (one year after moving to staging seems a good time for me to remove stuff that nobody address the issues at staging
<br> again, this is something that we should likely discuss at media summit:
<br> how many time a driver can stay at staging/ without having anything addressing from its TODO list that aren't checkpatch-related stuff
pH5: <u>hverkuil</u>: I think this is only used in i.MX21 to i.MX27, and was replaced by the PXP on i.MX28 / by the IPU on i.MX31.
hverkuil: <u>pH5</u>: OK, good to know. Would you know anyone who can test that driver? Or should we give up on it and mark it for removal?
mchehab: <u>sailus</u>: speaking on that, the last non-checkpatch/warning change at ipu3 driver was also back on Feb/2019 - the same month we move soc_camera to staging
<br> I'd say that the same criteria we apply for soc_camera should also be applied to ipu3
<br> (and to the remaining drivers under staging)
hverkuil: <u>mchehab</u>: not the same: soc_camera is under CONFIG_BROKEN; i.e. it is dead code. ipu3 isn't. That said, ipu3 is in the danger zone.
mchehab: It still builds:
<br> $ make M=drivers/staging/media/soc_camera
<br> <u>WARNING</u>: Symbol version dump ./Module.symvers
<br> is missing; modules will have no dependencies and modversions.
<br> CC drivers/staging/media/soc_camera/soc_camera.o
<br> CC drivers/staging/media/soc_camera/soc_mediabus.o
<br> CC drivers/staging/media/soc_camera/soc_mt9v022.o
<br> CC drivers/staging/media/soc_camera/soc_ov5642.o
<br> CC drivers/staging/media/soc_camera/soc_ov9740.o
<br> CC drivers/staging/media/soc_camera/imx074.o
<br> CC drivers/staging/media/soc_camera/mt9t031.o
<br> AR drivers/staging/media/soc_camera/built-in.a
<br> Building modules, stage 2.
<br> MODPOST 0 modules
hverkuil: but it doesn't actually work :-)
mchehab: ipu3 driver doesn't work either on my ipu3-based dell3 laptop :-p
<br> s/dell3/dell/
<br> no efforts to make it work on non-platform devices were done so far
<br> s/where/was/
pH5: <u>hverkuil</u>: I can ask around, a quick check didn't turn up anyone, and I don't see any connected mx27s in the lab net.
<br> <u>hverkuil</u>: apparently we had one in the lava lab, but I don't know the state of it.
sailus: <u>mchehab</u>: SoC camera has been obsolete for years.
<br> I'll submit a patch to change the MAINTAINERS entry.
mchehab: it is already on orphan state:
<br> S: Orphan
<br> we could add Obsolete too
sailus: Yes, that's what was suggested.
mchehab: but I did that patch already
sailus: Ack.
mchehab: https://patchwork.linuxtv.org/patch/57143/
ezequielg: <u>hverkuil</u>: ok, thanks. i'll add it to my TODO.
hfr: <u>sailus</u>: Hi Sakari, I don't understand your comment https://lkml.org/lkml/2019/6/20/640
<br> <u>sailus</u>: around v4l2_async_subdev as its first member
sailus: <u>hfr</u>: The V4L2 async framework will use that pointer to release the memory of the async sub-device.
<br> Looking again at the driver, it seems that the struct is embedded in a larger struct.
<br> Have you tried unbinding the driver?
<br> I'd expect a kernel oops...
hfr: <u>hfr</u>: I'll intensively do rmmod/modprobe, but I will redo with unbind/bind
<br> <u>sailus</u>: I'll intensively do rmmod/modprobe, but I will redo with unbind/bind
sailus: That shouldn't make a difference.
hfr: subdevs[0] = &dcmi->entity.asd;
<br> dcmi->notifier.subdevs = subdevs;
<br> struct dcmi_graph_entity {
<br> struct device_node *node;
<br> struct v4l2_async_subdev asd;
<br> is this incorrect ?
<br> why do "asd" must be at first place in struct dcmi_graph_entity ?
sailus: Because that pointer is used as an argument in a call to kfree later on.
<br> That's how the memory is released.
<br> And you're not supposed to embed it in another struct.
hfr: could you point me out a correct code ?
sailus: That might not be very well documented. It should be.
hfr: because It was initially absed on atmel-isi.c and I see same problem in this driver
sailus: The omap3isp and cio2 drivers use v4l2_async_notifier_parse_fwnode_endpoints().
<br> You could use that.
hfr: <u>sailus</u>: I've checked the code briefly
<br> tell me if I'm wrong or not
<br> in my driver I have:
<br> dcmi_graph_parse-> of_graph_get_remote_port_parent ->
<br> dcmi->entity.asd.match_type
<br> dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
<br> dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
<br> it seems that with code you pointed out, this is now made in v4l2_async_notifier_parse_fwnode_endpoints()
<br> perhaps it's the reason I have no trouble ?
<br> do I have to switch to v4l2_async_notifier_parse_fwnode_endpoints ?
sailus: <u>hfr</u>: You don't have to, but it'd simplify the driver a little.
<br> Another option would be to allocate the asd separately in the driver.
hfr: <u>sailus</u>: so currently, I just have to put "v4l2_async_subdev asd" at top of struct dcmi_graph_entity
<br> <u>sailus</u>: my next problem is around "dcmi->sensor" rename
<br> <u>sailus</u>: the initial problem was that now I have 2 subdevices to manage
<br> the first one is dcmi->entity.subdev => the bridge
<br> (previously it was the sensor)
<br> and I need a new subdev pointer to expose controls, formats, etc...
<br> this is the reason of rename
<br> now I understand that both subdevices have to be put in dcmi->entity to group subdevs related in a single struct$
<br> <u>sailus</u>: So I would propose to keep dcmi->entity.subdev as before, which points on directly connected remote subdev (without bridge, it's the sensor, with bridge it's the bridge)
<br> and add a new dcmi->entity.sensor which points to the last subdev of pipeline (see dcmi_find_sensor())
<br> if "sensor" naming hurts, we can find another one as "source"
<br> what do you think about this ?
sailus: A driver shouldn't care about subdevs that are not directly connected to the hardware it's in control of.
<br> I don't mind the naming, as long as it's reasonable.
hfr: <u>sailus</u>: have you checked my answer on DCMI bridge cover letter ?
jernej: paulk-leonov: I pushed my VP8 work here: https://github.com/jernejsk/linux-1/commits/cedrus-vp8 (last two commits)
<br> I tested this using ffmpeg
<br> I don't plan to work on this for a while, so you can take it over, if you want...
***: benjiG has left
ezequielg: <u>jernej</u>: and is that VP8 working?
jernej: as I said yesterday, no
<br> problem is that solution from AW uses VPU also for bitstream parsing
<br> and it automatically populates values in auxiliary buffer
<br> but I was unable to dump this buffer in order to check how to properly reconstruct values without the help of VPU
<br> a bit more work is needed
ezequielg: ah, ok.