djrscally: I agree with you about registration of video devices as soon as corresponding sensors are detected
pinchartl: Ah! Was planning to start a conversation about that tomorrow :)
It seems pretty straightforward...the contents of .complete() can be pretty much just moved to .bound()
I think I remember talking to kbingham and he had an argument against it though...although I can't remember what that was
one of the issues is that it could create race conditions with userspace
so the driver implementation may not be trivial
of course, one could argue that the complexity should be in the subsystem core, not in the drivers
and I would agree with that
Yeah, probably the best thing to aim for if possible
the ipu3 driver's the only notifier I've looked at really, was going to spend some time looking at how other notifiers do it
short answer, in a wide range of differently bad ways :-)
hah
That must mean they're differently good too, to balance out
neg: Could you rebase your patches touching async notifier stuff, including the rcar support, on my master branch?
djrscally: pinchartl: Hyvää iltaa!
sailus: hyvää yötä :-) mitä kuuluu ?
I have to confess the usual british ignorance of other languages, sorry
hauska nähdä sinua
Hyvää, kiitos.
But I assume; hello! :)
:-)
good evening / good night
Ah! Good evening
Registering the nodes as they're needed (vs. doing it all once) requires a few more things.
1. User space being able to figure out whether all the nodes have been registered and
2. a notify mechanism in MC.
sailus: that's true, but I think it's a cornercase
in most cases userspace processes that access cameras will start way later than drivers get loaded
pinchartl: I don't disagree actually.
And... there's no such thing as registering the nodes atomically anyway.
That said, the discussion a few years back concluded this is needed.
I think it's a useful feature, but it's no small development, and I don't think it should block moving forward with more common use cases
I actually have a few year old patches to implement support for media events.
Rebase and testing would be needed.
I have to admit I don't remember right not whether something is missing actually.
Although if hverkuil is fine with starting with less I have no problem with that.
starting with less, meaning to fix up the ipu3 driver alone for now?
djrscally: Yes.
Groovy
djrscally: does the i2c-designware driver return an arbitration lost error when there's no ACK from the device ?
sailus: Sure will do so tomorrow as I'm signing off soon. Will you send a PR for the rcar-csi2 patches delegated to you in patchwork?
That's what my reading this evening leads me to believe, yes
arbitration lost is supposed to mean that another master is operating the bus in a conflicting way
I could easily be wrong about that though
neg: Sent it a while ago. It only contains the rcar-csi2 patches though. The rest conflicts with the async notifier -> nf rename.
Oh; hmm
but the driver could implement this incorrectly
sailus: Thanks. I will look into the rename conflict first thing tomorrow
as it's unlikely that a real arbitration lost would occur consistently, it may be that something is pulling the data and/or clock lanes low unconditionally
possibly due to a lack of power
it's just a guess though
Tricky one; not having the device makes investigation a real pain
neg: Thanks.
sailus: Maybe I misunderstood you, I just checked your PR and all patches touching the notifier are in that. What series do you wish me to rebase?
neg: The notifier patches are in there, yes. But the rcar patches are not (apart from rcar-csi2), due to the conflict with the async notifier patches.
neg: rcar-vin: Add r8a779a0 support
pinchartl: This is the patch I saw relating to that error: https://lkml.org/lkml/2015/11/30/436
I haven't reviewed "media: rcar-isp: Add Renesas R-Car Image Signal Processor driver", but that is also affected. FYI.
sailus: Ahh I see, Hans already sent a PR that included that series and I half assumed that was already picked up
Ah.
Thanks for the info.
sailus: So how to best resolve the conflict? I can rebase in either direction, what ever is easiest. But I would love for both series to be picked up as both are needed to enable capture on r8a779a0
Worst case the notifer fix touching the VIN driver can be dropped from your PR and I can rebase that later
pinchartl: interestingly, the FMCN ACPI method Andy mentions in that patch note exists in the DSDT for Go/Go2's I2C busses
But the values are different
designware checks the hold time here: https://elixir.bootlin.com/linux/v5.14-rc2/source/drivers/i2c/busses/i2c-designware-common.c#L270
from those methods
Maybe worth trying the Go2's hold time on the Go...
neg: Let's discuss with hverkuil tomorrow.