ezequielg: I pinged one discussion for your noncoherent patches
hverkuil: hi, remember the "hotplug sensor" use case we discussed last week at ELCE? Was it part of the Media Summit discussion on Thursday?
also, is there a public report about the media summit discussions?
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
(I assume this is related to the fpd link discussion)
we have one issue to solve first though: object lifetime management is completely broken in MC and V4L2
that needs to be addressed to support any real hotplug use case
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
pinchartl: thanks. yes, it is related to the fpd discussion
pinchartl: by "object lifetime management is completely broken in MC and V4L2" do you mean it has design flaws or just software bugs?
both if I remember correctly (it's been a long time)
Sakari has worked on it, but those efforts are currently stalled
it's a complex issue that requires cooperation with drivers
as in every driver needs to be patched to be safe
last time patches were proposed Mauro wasn't convinced that the approach was right
and claimed that the patches introduced a regression as they didn't fix every driver in one go
the counterclaim was that all drivers are currently broken
in a nutshell, we started from position A with big race condition windows due to missing lifetime management
Mauro then committed a large rework of the MC core he wrote
moving to position B
where the race still exists, but with a much smaller window
we need to go to C, fixing the issue correctly
but C happens to be on the other side of A, so we have to undo B
the proposal is to revert B and implement C correctly
while Mauro wanted us to fix the problem without increasing the size of the race condition window at any point in the series
and the result is that nothing happened for a long time (I'd say about a year, could be longer)
it's pretty easy to crash the kernel today with an MC device
and I wouldn't be surprised if it could be exploited
pinchartl: Mauro was fine with the approach AFAIR; the current issue is that the patchset breaks DVB device unbinding.
(I wouldn't consider any Linux system with a V4L2 device to be safe)
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.
sailus: I thought we were still blocked on the approach that required drivers to be individually patched, has that been sorted out ?
that at least would be good news :-)
pinchartl: thanks for the info
unfortunately this means implementing my use case will require hacks and make my next driver non-mainlineable :(
lucaceresoli: or you could try to help solving the underlying issues :-)
pinchartl: why not, if there are small tasks that I can tackle
any experience with dvb ?
but it won't be in my next product @job
for an obvious timing mismatch...
pinchartl: no experience with dvb [except turning ON my TV :)]
then you have a great opportunity to gain experience in that field :-D
sailus: any way the work could be parallelized ?
pinchartl: Drivers for hot-pluggable hardware should be fixed, indeed.
But that's mostly work as usual I presume.
I mean to unblock the dvb unbinding problem. does that require patching all drivers, or can it be fixed in the core ?
I don't remember anymore whether it could be a problem in DVB core or the drivers.
Could be either.
DVB drivers would still need to be patched for media device refcounting.
of course
but I don't think that should block progress
The old API is still available but it has all the same problems it used to.
I'll rebase the set and push in the near future.
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 ?
jhautbois: yes. no public code, it is still too early for anything decent. ARM64 xilinx zynqmp.
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?
jmondi, yes, here : http://www.ti.com/tool/DS90UB954-Q1EVM
lucaceresoli, ok, interesting, any idea on a first public proposal ? I can try it on my i.MX6 and maybe amend it if necessary
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.
ok, but Vladimir seems to be working only on the display part...
jhautbois: thanks ;)
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)
Hi, anyone knows if there is incompatibility between CSI versions ?
for example, my DS90UB954 "sensor" is MIPI DPHY Version 1.2 / CSI-2 Version 1.3
and the i.MX6 is MIPI DPHY Version 1.00.00 / CSI-2 Version 1.0
I'd assume newer versions can maybe run a bit faster
support for additional formats etc
but there shouldn't be any incompatibilities at the protocol level