<!-- 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>
ezequielg: <u>hverkuil</u>: thanks for reviewing!
hverkuil: no problem.
<br> I just posted "[PATCHv2 00/12] Stateful/stateless codec core support". Please review since I would like to merge patches 1-7 and possibly patch 8 as well for v5.4.
<br> Who else besides me plans to attend the ELCE this year? If there is enough interest, then it might be useful to see if we can meet to discuss codec support and libcamera support (as suggested by Alexandre Courbot).
koike: <u>hverkuil</u>: I plan to be there, and I think ezequielg too
ezequielg: indeed.
hverkuil: and I know dafna2 will be there as well :-)
ezequielg: and bbrezillon iirc.
hverkuil: <u>ndufresne</u>: will you attend the ELCE?
bbrezillon: <u>hverkuil</u>: yep, I'll be there, and I'm definitely interested
hverkuil: <u>pinchartl</u>: will you be there as well?
<br> (esp. w.r.t. libcamera discussions)
pinchartl: <u>hverkuil</u>: I will be there
<br> I'll be available on the Thursday after the conference
<br> or during the conference
<br> there will be a presentation about libcamera at ELCE
hverkuil: <u>pinchartl</u>: great.
<br> I might decide to attend the Automated Testing Summit on the Thursday, depending on the program. But we should be able to find time during the conference at least.
pinchartl: I was considering it too, but I don't think it brings that much value in the areas I'm interested in
<br> I'm more focussed on efforts regarding writing tests than endlessly discussing Fuego vs. Jenkins vs. ...
jmondi: I'm attending ELC-E and beside the libcamera presentation, I would love to be in the same room (again) with sailus to keep discussing about multiplexed stream support :)
hverkuil: <u>pinchartl</u>: that's why I am waiting to see the program before making a decision :-)
<br> <u>sailus</u>: do you know yet if you will attend the ELCE?
<br> <u>tfiga</u>: ndufresne: ezequielg: mripard: bbrezillon: svarbanov: pH5: gnurou: mjourdan: paulk-leonov: please review https://patchwork.linuxtv.org/project/linux-media/list/?series=547
<br> If there are no more comments, then I want to make a PR for patches 1-7 and possibly 8 on Friday.
sailus: <u>hverkuil</u>: I haven't planned to travel there yet, at least.
<br> Any particular reason why you're asking?
<br> Ah, libcamera.
jmondi: and multiplexed streams :)
sailus: Oh well.
hverkuil: <u>sailus</u>: your Ack for the stm32-dcmi driver is for the whole series? Just to confirm.
sailus: <u>hverkuil</u>: I only acked the first patch.
<br> I'm frankly not at all certain I like v5 better than v2.
<br> For instance, what'll happen when the bridge doesn't use the same format on its sink and source pads?
<br> With MC, the user would be responsible for configuring that, but with stm32-dcmi, it's inside the driver.
hverkuil: Looking at the code this seems to be handled correctly: it negotiates a valid media bus format with the sensor (that's already in the current driver), then propagates that through the pipeline.
ezequielg: <u>mchehab</u>: hey Mauro, are you OK with "[PATCH] media: Clarify how menus are hidden by SUBDRV_AUTOSELECT" https://patchwork.linuxtv.org/patch/57766/?
sailus: <u>hverkuil</u>: For some formats setting the format on the sensor may not work.
hverkuil: <u>sailus</u>: can you reply with your concerns?
sailus: Yeah.
<br> A little later today.
hverkuil: thanks!
mani_s: Can someone review this patchset? https://lkml.org/lkml/2019/8/6/489
<br> sailus, hverkuil ^
sailus: <u>mani_s</u>: Possibly today, more likely tomorrow.
hfr: <u>sailus</u>: Hi Sakari, so your acked-by was only for patch 1/3 ?
<br> <u>sailus</u>: r you available to discuss on what remains ?
sailus: Yes.
<br> And yes.
<br> I have time now, if you're around as well.
hfr: yes
sailus: The media bus formats may be different on each pad of the bridge subdev.
<br> Does setting the format work currently for such formats?
<br> As far as I can see, the dcmi driver is attempting to set the parallel variant of the format on the sensor --- that is CSI-2.
<br> In many cases the formats are the same but not always.
hfr: as the mipid02 bridge do not make format conversion I haven't encountered this case yet
sailus: The formats used on CSI-2 are those parallel formats that transfer a sample on a single cycle.
hfr: I remember of a conversion func inside mipid02, let me check
sailus: Looking at the driver, there are some JPEG and RGB formats using two clocks per sample.
hfr: static __u32 serial_to_parallel_code(__u32 serial)
<br> {
<br> if (serial == MEDIA_BUS_FMT_UYVY8_1X16)
<br> return MEDIA_BUS_FMT_UYVY8_2X8;
<br> if (serial == MEDIA_BUS_FMT_BGR888_1X24)
<br> return MEDIA_BUS_FMT_BGR888_3X8;
<br> in mipid02
sailus: I guess the dcmi driver could figure that out, in principle.
hfr: it's not crystal clear to me the serial format versus parallel format
<br> I have checked other CSI-2 drivers as well and they are handling parallel format, so I'm confused
sailus: All of the above formats are being used on parallel busses but on serial busses we opted to use the parallel formats using a sample / single clock.
<br> So you shouldn't be able to find a CSI-2 driver that uses yXz variant where y is greater than one.
hfr: ov5645.c is CSI-2 and support MEDIA_BUS_FMT_UYVY8_2X8
<br> same for ov5640
<br> which is CSI and //
sailus: In other words, if you're trying to set such a format on a driver for a device using CSI-2, you can't expect it to work.
<br> That may be a driver bug.
<br> Most likely it is.
hfr: https://patchwork.kernel.org/patch/10986315/
<br> so this patch is not good
<br> and ov5640 is also not OK
<br> as 5645
<br> and certainly many others
<br> So I wonder: if a sensor driver support both parallel and CSI-2 output, there will be 2 different bus formats for the same pixel format, for example RGB565
<br> or YUYV
<br> how to handle this ?
<br> this is why I made it simple: align on parallel ones...
sailus: The driver is responsible for supporting the correct format, depending on which bus type is used.
hfr: so how to move forward on this ?
sailus: One way is to take that change in the media bus code in the function handling the pipeline configuration.
<br> I guess a comment beginning with FIXME and explaining the situation would do as well.
hfr: ok, so in dcmi_pipeline_s_fmt()
<br> at comment /* Propagate format on sink pad if any, otherwise source pad */
<br> before call of v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, &fmt);
sailus: You'd basically need to walk the pipeline backwards while configuring the formats on the way to see which format to set on the sensor.
hfr: format is asked by user, so I have to find the closest one supported by driver, something like that
<br> I don't feel cumfortable with that
<br> I could at least do similarly as in mipid02 in func: serial_to_parallel_code
<br> for ex. convert RGB565_2X8_LE to RGB565_1X16
sailus: <u>hfr</u>: A question: is mipid02 a hardware block inside a SoC, or can it be found as a discrete chip?
hfr: discrete chip
sailus: Otherwise you could have assumed you have mipid02 (and no other bridge chip) connected.
hfr: More generally, with bridges that handles bus code conversions, how is solved the pipeline negotiation ?
sailus: Generally the formats along the pipeline are configured from the user space.
hfr: OK, but anyway the userspace has to solve it
sailus: For in the general case it's unfeasible to configure them purely based on the in-memory format.
hfr: What I have seen for the time being is hardcoded values in pipeline
sailus: That may be, but it's still use case specific.
hfr: coming back on dcmi, I can do something quite simple: if subdev_call(s_fmt) fails, I try with the serial equivalent code
<br> for ex. RGB565_2X8_LE to RGB565_1X16, YUYV8_2X8 => YUYV8_1X16, ...
<br> or I can use an information from the subdev pad that this pad only support serial codes
<br> and do the conversion based on this
<br> I don't know if I have this information somewhere
<br> searching in platform drivers, I see that rcar-csi2.c is handling some"2X" formats:
<br> { .code = MEDIA_BUS_FMT_UYVY8_2X8, .datatype = 0x1e, .bpp = 16 },
<br> { .code = MEDIA_BUS_FMT_YUYV10_2X10, .datatype = 0x1e, .bpp = 20 },
<br> { .code = MEDIA_BUS_FMT_YUYV8_1X16, .datatype = 0x1e, .bpp = 16 },
<br> { .code = MEDIA_BUS_FMT_UYVY8_2X8, .datatype = 0x1e, .bpp = 16 },
<br> ok so they accept both parallel and serial bus code, for which the same value is configured to 0x1e/16
<br> isn't it the best to do to get rid of this problem ?
sailus: CSI-2 drivers shouldn't need to deal with different mbus codes for the same format.
<br> That's why only one is used.
hfr: another option: does the subdev_call(s_fmt) behaves as its V4L2 equivalent, ie if we set a format, the subdev driver will configure itself on the closest one that it can handle and return this format
<br> ?
<br> so dcmi could inject the // bus code and receive in return the serial code
sailus: Sorry, no; you can't work around bugs in your driver in all other drivers.
hfr: ok, so I will add a FIXME that this code will not work for some parallel codes ?
sailus: That's ok for me if Hans agrees.
<br> I'll check again the set.
<br> I'll need to leave now, back tomorrow if not earlier.
hfr: OK, thanks for all Sailus !
ezequielg: paulk-leonov: Hi Paul! I have just submitted a v5 for the h264 series, this is tested on cedrus (same as v4). Do you think you can take a look at the cedrus patches?
koike: Hi sailus , quick question regarding your review on rockchip isp1 driver: I'm trying to aliminate the array "p->subdevs[p->num_subdevs++] = sd;" , so I'm looking to omap3isp, when v4l2_subdev_call(... s_stream, on) fail, should it call v4l2_subdev_call(..., s_stream, off) to the ondes that didn't fail at https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/omap3isp/isp.c#n709 ?
<br> <u>sailus</u>: I'm just wondering if omap3isp is wrong or if I can do the same
sailus: <u>koike</u>: In general, yes.
<br> The subdevs that started streaming need to be stopped if another one failed.
<br> Otherwise those subdevs will continue to be in streaming state, well, forever.
koike: <u>sailus</u>: right, thanks, then omap3isp doesn't seem to be doing that (I can send a patch against omap3isp but I won't be able to test it)
<br> I'm having a hard time finding a good example, camcss-video.c also seems to be doing the same
<br> xilinx-dma.c also seems to do the wrong thing, the only one I found that looks correct is omap4iss/iss.c