[02:23] <tfiga> ezequielg: I pinged one discussion for your noncoherent patches
[09:01] <lucaceresoli> hverkuil: hi, remember the "hotplug sensor" use case we discussed last week at ELCE? Was it part of the Media Summit discussion on Thursday?
[09:02] <lucaceresoli> also, is there a public report about the media summit discussions?
[09:03] <pinchartl> lucaceresoli: we have discussed fault-tolerant V4L2, and that included discussions about cameras being absent when the system boots up either because they were defective, or because they would appear later
[09:03] <pinchartl> (I assume this is related to the fpd link discussion)
[09:03] <pinchartl> we have one issue to solve first though: object lifetime management is completely broken in MC and V4L2
[09:04] <pinchartl> that needs to be addressed to support any real hotplug use case
[09:04] <pinchartl> regarding public reports, shared notes have been taken, and I assume Hans or Mauro will post a report as they have usually done in the past
[09:05] <lucaceresoli> pinchartl: thanks. yes, it is related to the fpd discussion
[09:06] <lucaceresoli> pinchartl: by "object lifetime management is completely broken in MC and V4L2" do you mean it has design flaws or just software bugs?
[09:06] <pinchartl> both if I remember correctly (it's been a long time)
[09:07] <pinchartl> Sakari has worked on it, but those efforts are currently stalled
[09:07] <pinchartl> it's a complex issue that requires cooperation with drivers
[09:07] <pinchartl> as in every driver needs to be patched to be safe
[09:07] <pinchartl> last time patches were proposed Mauro wasn't convinced that the approach was right
[09:08] <pinchartl> and claimed that the patches introduced a regression as they didn't fix every driver in one go
[09:08] <pinchartl> the counterclaim was that all drivers are currently broken
[09:08] <pinchartl> in a nutshell, we started from position A with big race condition windows due to missing lifetime management
[09:08] <pinchartl> Mauro then committed a large rework of the MC core he wrote
[09:09] <pinchartl> moving to position B
[09:09] <pinchartl> where the race still exists, but with a much smaller window
[09:09] <pinchartl> we need to go to C, fixing the issue correctly
[09:09] <pinchartl> but C happens to be on the other side of A, so we have to undo B
[09:09] <pinchartl> the proposal is to revert B and implement C correctly
[09:10] <pinchartl> while Mauro wanted us to fix the problem without increasing the size of the race condition window at any point in the series
[09:10] <pinchartl> and the result is that nothing happened for a long time (I'd say about a year, could be longer)
[09:11] <pinchartl> it's pretty easy to crash the kernel today with an MC device
[09:11] <pinchartl> and I wouldn't be surprised if it could be exploited
[09:11] <sailus> pinchartl: Mauro was fine with the approach AFAIR; the current issue is that the patchset breaks DVB device unbinding.
[09:12] <pinchartl> (I wouldn't consider any Linux system with a V4L2 device to be safe)
[09:12] <sailus> And note it's just a start: it only addresses the object lifetime issue for the media device ifself, not e.g. for sub-devices.
[09:12] <pinchartl> sailus: I thought we were still blocked on the approach that required drivers to be individually patched, has that been sorted out ?
[09:15] <pinchartl> that at least would be good news :-)
[09:17] <lucaceresoli> pinchartl: thanks for the info
[09:18] <lucaceresoli> unfortunately this means implementing my use case will require hacks and make my next driver non-mainlineable :(
[09:21] <pinchartl> lucaceresoli: or you could try to help solving the underlying issues :-)
[09:22] <lucaceresoli> pinchartl: why not, if there are small tasks that I can tackle
[09:23] <pinchartl> any experience with dvb ?
[09:23] <lucaceresoli> but it won't be in my next product @job
[09:23] <lucaceresoli> for an obvious timing mismatch...
[09:24] <lucaceresoli> pinchartl: no experience with dvb [except turning ON my TV :)]
[09:25] <pinchartl> then you have a great opportunity to gain experience in that field :-D
[09:25] <pinchartl> sailus: any way the work could be parallelized ?
[09:26] <sailus> pinchartl: Drivers for hot-pluggable hardware should be fixed, indeed.
[09:26] <sailus> But that's mostly work as usual I presume.
[09:27] <pinchartl> I mean to unblock the dvb unbinding problem. does that require patching all drivers, or can it be fixed in the core ?
[09:27] <sailus> I don't remember anymore whether it could be a problem in DVB core or the drivers.
[09:27] <sailus> Could be either.
[09:28] <sailus> DVB drivers would still need to be patched for media device refcounting.
[09:28] <pinchartl> of course
[09:28] <pinchartl> but I don't think that should block progress
[09:28] <sailus> The old API is still available but it has all the same problems it used to.
[09:32] <sailus> I'll rebase the set and push in the near future.
[09:42] <jhautbois> lucaceresoli, I saw on ML that you are working on ds90* (de)serializer(s) ? Do you have a piece of code somewhere, which is maybe WIP ? On which platform are you testing it ?
[09:48] <lucaceresoli> jhautbois: yes. no public code, it is still too early for anything decent. ARM64 xilinx zynqmp.
[09:50] <jmondi> jhautbois: Hi there, I recall you mentioned an FPD-Link test platform available for general purchase... could you please recall me its name? Was that produced by TI directly?
[09:59] <jhautbois> jmondi, yes, here : http://www.ti.com/tool/DS90UB954-Q1EVM
[10:00] <jhautbois> lucaceresoli, ok, interesting, any idea on a first public proposal ? I can try it on my i.MX6 and maybe amend it if necessary
[10:05] <lucaceresoli> jhautbois: I cannot estimate any timing, sorry. Also since Vladimir is at a more advanced stage, it is possible that my work will just be an addition to his one.
[10:07] <jhautbois> ok, but Vladimir seems to be working only on the display part...
[10:19] <jmondi> jhautbois: thanks ;)
[10:56] <lucaceresoli> jhautbois: according to Vladimir, "there is no big difference between camera and display ICs from the series" (https://lkml.org/lkml/2018/10/31/171)
[15:21] <jhautbois> Hi, anyone knows if there is incompatibility between CSI versions ?
[15:21] <jhautbois> for example, my DS90UB954 "sensor" is MIPI DPHY Version 1.2 / CSI-2 Version 1.3
[15:21] <jhautbois> and the i.MX6 is MIPI DPHY Version 1.00.00 / CSI-2 Version 1.0
[16:39] *** benjiG has left 
[17:34] <larsc> I'd assume newer versions can maybe run a bit faster
[17:35] <larsc> support for additional formats etc
[17:35] <larsc> but there shouldn't be any incompatibilities at the protocol level