#linux-media 2021-07-25,Sun

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

[22:05]

pinchartl

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

[22:07]

djrscally

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

[22:11]

pinchartl

short answer, in a wide range of differently bad ways :-)

[22:12]

djrscally

hah
That must mean they're differently good too, to balance out

[22:13]

sailus

neg: Could you rebase your patches touching async notifier stuff, including the rcar support, on my master branch?
djrscally: pinchartl: HyvÃ¤Ã¤ iltaa!

[22:18]

pinchartl

sailus: hyvÃ¤Ã¤ yÃ¶tÃ¤ :-) mitÃ¤ kuuluu ?

[22:20]

djrscally

I have to confess the usual british ignorance of other languages, sorry

[22:21]

pinchartl

hauska nÃ¤hdÃ¤ sinua

[22:21]

sailus

HyvÃ¤Ã¤, kiitos.

[22:21]

djrscally

But I assume; hello! :)

[22:21]

pinchartl

:-)
good evening / good night

[22:21]

djrscally

Ah! Good evening

[22:21]

sailus

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.

[22:23]

pinchartl

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

[22:24]

sailus

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.

[22:26]

pinchartl

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

[22:28]

sailus

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.

[22:28]

Although if hverkuil is fine with starting with less I have no problem with that.

[22:34]

djrscally

starting with less, meaning to fix up the ipu3 driver alone for now?

[22:41]

sailus

djrscally: Yes.

[22:44]

djrscally

Groovy

[22:45]

pinchartl

djrscally: does the i2c-designware driver return an arbitration lost error when there's no ACK from the device ?

[22:52]

neg

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?

[22:53]

djrscally

That's what my reading this evening leads me to believe, yes

[22:53]

pinchartl

arbitration lost is supposed to mean that another master is operating the bus in a conflicting way

[22:53]

djrscally

I could easily be wrong about that though

[22:53]

sailus

neg: Sent it a while ago. It only contains the rcar-csi2 patches though. The rest conflicts with the async notifier -> nf rename.

[22:53]

djrscally

Oh; hmm

[22:54]

pinchartl

but the driver could implement this incorrectly

[22:54]

neg

sailus: Thanks. I will look into the rename conflict first thing tomorrow

[22:55]

pinchartl

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

[22:55]

djrscally

Tricky one; not having the device makes investigation a real pain

[22:57]

sailus

neg: Thanks.

[22:58]

neg

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?

[22:59]

sailus

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

[23:01]

djrscally

pinchartl: This is the patch I saw relating to that error: https://lkml.org/lkml/2015/11/30/436

[23:02]

sailus

I haven't reviewed "media: rcar-isp: Add Renesas R-Car Image Signal Processor driver", but that is also affected. FYI.

[23:03]

neg

sailus: Ahh I see, Hans already sent a PR that included that series and I half assumed that was already picked up

[23:03]

sailus

Ah.
Thanks for the info.

[23:03]

neg

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

[23:05]

djrscally

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...

[23:08]

..... (idle for 22mn)

sailus

neg: Let's discuss with hverkuil tomorrow.

[23:31]

***

djrscally has quit IRC (Ping timeout: 480 seconds)

[23:33]

↑back Search ←Prev date Next date→ Show only urls

(Click on time to select a line by its url)