gnurou: what's your interest on vicodec?
gnurou: that's a good idea, yes. in fact, vim2m uses delayed_work so it can simulate a hardware doing actual work, and not complete the work in .device_run.
ezequielg_: I am just using it as a reference V4L2 codec that I can use without any particular hardware to experiment with user-space.
ezequielg_: ok, in that case I'll probably take inspiration from vim2m and try to reproduce the execution model in vicodec. That should make it closer to how actual hardware works/
My v4l2-subdev camera sensor driver is meanwhile in a better shape and now I'm trying to implement some features. One is: The sensors sequencer can be enabled/disabled and I like to use this to take a single picture at a very specific time (there is also a Trigger-GPIO input on the sensor). My question for you: Is there a default way in v4l2 to take a single picture (as soon as possible when a trigger/sequencer is pulled)? What I'm currentl
y doing: I added a special driver specific v4l-ctl (type boolean, named V4L2_CID_SEQUENCER), I start capturing in userland and as soon as I enable the sequencer I get pictures coming in, I can pause it (instantly) by v4l-ctl and restart it frame accurately. Is that the way to go?
sailus: Good afternoon! Do you think we could have the ov02a10 driver merged now?
(for your convenience: https://patchwork.kernel.org/cover/11656187/)
tfiga: Wow, I'll use this as inspiration for my driver I'm currently writing.
kalpu: I guess it depends on whether sailus thinks it's ready to be merged :)
but possibly reading the review comments for the previous revisions could be useful
tfiga: nice tip, thanks. Regarding your yaml docu: ovti,mipi-tx-speed: I don't get why the voltage is important there. Your explanation is about Voltage and the enum describes some Mhz??
tfiga: Good question.
tfiga: I know :)
That would leave the drive strength matter unresolved.
It could be that it's hard to find a way to come up with a correct value for different sensor configurations on a given platform.
sailus: that's the only infromation we get from the vendor
I know...
How about setting a value for each link frequency?
that's not what we have in our systems
as I explained below
before*
we need different voltages on different boards, with the same link frequencies
I meant in DT.
ah
that probably makes sense
The driver currently supports a single link frequency, so it'd mostly be a semantic change.
tfiga: I still don't undertand the setting and the explanation. If you don't get info, do you understand "your" explanation of the setting?
A change in bindings, plus the driver would need to read the TX speed property as an array.
kalpu: we just get the "correct" values for the parameters
And use the value corresponding to the link frequency.
everything else is pure guess
tfiga: okay, thanks :) I guess I know what you mean. Why is that so secret over all?
I don't know :)
tfiga: "Frequency of the eclk clock in Hertz." I can read in your yaml, what is eclk?
do you mean "clk" ?
eclk is the input clock of the sensor
as you can see in the clock-names property
ah okay, i see - thanks!
although the description could be a bit better...
hmm, I thought someone reviewed the DT bindings
but I can see some weird things still there
tfiga: Maybe another silly question: freq_mux is not described right? And in your example I cannot se a value set... is this intentional?
it shouldn't be there
So up for round v14 ?
that's the weird thing I referred to above
^^
<- I'm not that fast :) ...
tfiga: "Update max exposure while meeting expected vblanking", that's what I'm now up to implement.
sailus: how do you envision matching the voltages to clocks?
since modes are specific to the driver implementation, the DT binding can't really refer to them
kalpu: okay :)
tfiga: The mode determines the CSI-2 bus frequency.
I think this driver should have it right, but it of course depends on the exact behavior of your sensor
I understand the required drive strength is bound to that.
sailus: would something like an array of frequency, drive strength pairs work?
I think that seems like the only future-proof approach discussed so far.
As more sensor modes can be added without assuming something about the board.
tfiga: I would recommend that as well. Drive strength in my experience is HW dependent. Too high or too low can cause problems. Usually the recommended default is fine, but for unusual designs (such as long or extremely short wire lengths) you may need to make changes.
hverkuil: that's what we did
but apparently it might have to be different per link frequency
tfiga: That's what DT binding documentation strongly suggests.
It should be an optional property, I think. In most cases you don't need it. And yes, it can differ per frequency range.
It's a little odd that we have quite a few sensor drivers out there but this is the first time we need something like this.
I guess it's just because the default has been fine for everyone so far?
Most programmers don't care once they see it's working. :-)
I'm having some issues with mipi and detecting the clock signal, maybe this is related to vltage and mipi-power-down-mode... there is an fpga involved, so I guess this can happen?
sailus: that it's visibly working doesn't mean that it's correct :)
I know...
in our case, some MIPI signal integrity tests would fail with the wrong value
but the camera would still work "fine"
And if there are issues, they may only be seen in one of 100 units or such.
exactly
tfiga: So you do have the right equippment to analyze even mipi signals?
One more reason to have the link-frequency property.
kalpu: our software team doesn't, but whoever we work on the hardware side has to have it
nice
tfiga: I'll reply to the patch.
I'm replying right now
Ack.
perhaps you could hold on a moment and then correct me ;)
There's still time to get it in.
tfiga: Thanks!
I have a question regards taking pictures/snapshots at a specific time. I posted it here some hours ago. Can I just repost my question or what is considered "good behaviour" here? :)
sailus: but it's still not clear how the values map
but I guess maybe it doesn't matter
as long as one can give something like an OPP table
and the value for the nearest not less than frequency would be selected
tfiga: The frequency the driver uses is one of those in the link-frequencies.
So the corresponding entry in the drive strength array would be used for that frequency.
hmm
why do we have link-frequencies in DT?
One of the reasons is that the CSI-2 bus isn't using a frequency that's causing problems elsewhere in the system.
I suspect it doesn't matter for usual production use cases, but it could be limiting for
other users
it's kind of a policy thing
I'd guess in general it's undesirable having unknown high frequencies to be used on an unshielded lines over large stretches of the PCB.
certainly in production
It's especially so on mobile phones, that may have a large number of radios, for instance.
but there are also some hobbyist use cases
and small embedded projects
(And I don't mean the FM kind.)
Yes, sure.
They can also add the frequencies to DT.
well, I guess with DT it's at least easier than with ACPI
X-)
I suppose that the idea of having a DTB burned into the device firmware is gone
I don't know.
But basically the know-good frequencies are a property of the hardware.
it's a good name
it's exactly a list of frequences which are known to be good
but there might be some unknown, but still good
Yes, that's entirely possible.
They can be added to the list in that case.
does this property also apply to ACPI?
Usually there are two reasons why one might want to have a frequency in that list.
Those are link speed and power consumption.
Yes, it does.
It's really difficult to override those
take a random ACPI laptop, the tables won't even recompile
I know...
But on those machines there's no list of known-good frequencies there either, it's hard-coded in drivers most of the time.
I'd see the properties there as hints
and the driver could still be asked to ignore those
for example ov02a10.ignore_fw_hints=1
The driver doesn't know whether it's running on a production system or not.
So the tighter requirements should be upheld.
ideally, we would expose the information whether a mode is blessed or not to the userspace
A "Do you want to break things" kind of message? :-)
I haven't heard of an actual need to deviate from that.
Instead, the drivers themselves are what are blocking things from being done.
well, there relation might be bidirectional
the drivers could be as such, because they have no way to be the other way around
No, it really isn't.
I'm not sure about this
but anyway, I guess we can define the properties for now
and making them optional in the future is easier than making them mandatory :)
mchehab: Bom dia!
sailus: moikka!
mchehab: How do you do?
kalpu: I think we should standardize a control for that. maybe V4L2_CID_CAPTURE_TRIGGER ?
(if I understand your question correctly)
sailus: fine, and you?
Fine, too, thanks!
I looked at the glossary a little more again and I think some terms we've used for quite a while may need some rework.
Such as the bridge driver.
A bridge is a device that receives the data from one bus and transmits it on another. But the latter may not be a memory bus, in which case the DMA (or memory output) is somewhere else.
We do already have quite a few CSI-2 -- parallel bridge drivers that just do not function as such master drivers (in absence of a better term).
sailus: the term "bridge driver" is used at the glossary in order to define the driver with creates /dev/video* (& radio/vbi/sdr/...) devnodes
yeah, I agree that other "bridges" may be present, like the CSI-2 ones
not sure how to distinguish between them at the glossary.
do you have some proposal?
basically, we're using "bridge" term to refer to the driver that bridges the CPU to access the buses that are there to control the media peripherals
(in practice, USB, PCI, SDIO, ... to I2C)
on SoC, this can be a little bit shady, as usually there is an ISP and/or other IP components with works as bridge to allow doing I/O at the peripherals
that can be integrated at a single silicon
the term "bridge driver" is the one we've been using - even not being 100% accurate
if you have a better term, feel free to propose
I'm not sure "master driver" is better, albeit it's not bad either IMO.
yeah, I remember we used "master driver" for a while
What happened then? :-)
well, it is not that precise when we have MC
also, nowadays, I would avoid using the term "master" - as some people born in US think it is offensive
With MC, there's a similar master driver that handles the MC device.
I wonder if that's a misunderstanding or something.
We don't really have a name for that driver (apart from master driver).
"Driver that registered the media device" has been used, too, but that's very cumbersome.
https://lore.kernel.org/ksummit-discuss/20200726153054.GA5925@pendragon.ideasonboard.com/T/#t
(for discussions about "master" word)
alternatives have been proposed for "master", like "controller" and others
I'm yet to see something that would propely replace "master" on all places it is used
is it just me, or IRC is too unstable today? I'm getting a lot of:
IRC connection timed out.  Reconnecting...
The vast majority of that discussion is circling around the pair master--slave *together*.
yeah, but some argue that master should not be used at all
for me, I don't have myself any restrictions - neither of those words exist in Portuguese - except when used with computer science
:-D
:-p
X-)
the Brazilian translation for "master" also doesn't carry any bad meaning
Nor does the English term.
in any case, I guess we should avoid using it
sailus: at that long discussion, some argued that the word "master" alone has bad meanings in English
Slave is more connected to slavery, indeed, of the definitions gcide, only one of a large number of them is *not* related to human slaves.
anyway, let's try to get rid of using such terms
Whereas for "master" there's just one: that related to slaves.
(probably not possible to avoid on some cases)
in this specific case, we might use "controller driver"
instead of "bridge driver"
We already have media controller.
That'd be confusing for newcomers.
yep, things can get confusing
https://www.merriam-webster.com/thesaurus/master
Synonyms for master boss, boss man, captain, chief, foreman, head, headman, helmsman, honcho, jefe, kingpin, leader, taskmaster
Words Related to master directress, mistress administrator, commander, director, executive, general, governor, hierarch, higher-up leadman, manager, overseer, principal, skipper, standard-bearer, steward, straw boss, superintendent, superior, supervisor
maybe "manager driver" ?
"principal driver"?
As in school?
But I like "honcho".
I can't see us having "mistree drivers" though.
s/tree/tress/
"principal" can be director, but it also means "main"
I guess we used "main driver" for a while
"lead driver" may also work
Main driver might work at least in case of MC.
I wonder what people might think of "overlord driver".
At least the meaning is unambiguous.
for non-MC, "main driver" works
In MC, the master driver has less control over the subdev drivers.
That control is there without MC.
The term "main driver" does not really convey that.
Although this is unlikely to be a practical issue.
yeah, on MC, "main driver" is not 100% accurate
but probably it won't be an issue if we use this term
maybe "general driver" or "general media driver" could also work
Could people between general and generic?
I think master or main are good so far.
Main works here in practice IMO.
Synonyms for master arch, big, capital, cardinal, central, chief, dominant, first, foremost, grand, great, greatest, highest, key, leading, main, number one (also No. 1), numero uno, overbearing, overmastering, overriding, paramount, predominant, preeminent, premier, primal, primary, principal, prior, sovereign (also sovran), supreme
(as adjective)
"Supreme!"
that's it :-p
Words Related to master distinguished, eminent, illustrious, noble, notable, noteworthy, outstanding, prestigious, signal, star, stellar, superior high-level, senior, top important, influential, major, mighty, momentous, significant incomparable, matchless, unequaled (or unequalled), unparalleled, unsurpassed celebrated, famed, famous, renowned
"famous driver" :-X
"Bow to the supreme driver!"
(That said, master and main are entirely workable.)
mchehab: What happened to the "media device complex"?
I thought it was really handy.
We spent a lot of meeting time to come up with that.
Many TCP segments were transmitted.
I ended removing it, it ended not being needed, after some cleanups at the texts
And received.
It's a really handy way to refer to all those hardware devices that can be viewed as a single device by the user.
also, I started using the word "complex" as an opposite to "simple" on some e-mails
and discussions (during the discussions related to libcamera)
Complex has many meanings.
IMHO, complex works a lot better as an opposite to simple
using it on other contexts can be confusing, IMO
that's said, I'm open to new glossary terms
It's a noun there, not an adjective.
I don't think there would be confusion.
now that we have a "basic set" , I expect that the glossary will grow as needed within the docs
Yes, we can add it if needed.
sailus: I hear you. The point is that the text that were using it got changed and stopped needing it
so, I removed from the glossary.
it was already too much efforts to get into something acceptable ;-)
Yes.
so, on the last reviews, I reduced from 7 to 4 patches
Thank you for doing all this work on the terms.
and simplified several things
anytime
back to "bridge driver" - I'm OK with "main driver"
I'd actually use "media device complex" to describe the main driver. Hmm.
Or I can describe the same separately, without using the term.
IMHO, "media device complex" is not "main driver"
I mean, we used the term "complex" on that time to refer to the entire hardware
all media hardware components
the "main driver/bridge driver" is used to refer just to the part of the device that has the DMA engine for transfering video buffers
so, just a small set of the "complex"
"stream I/O transfer driver" would likely be a more technical term
(although too big, IMHO)
(and probably not too precise when referring to non-MC devices)
Phone call.
Back.
The media device complex is a set of related devices.
yes. the main driver is just one device
or, actually, the driver for just one drvice
I'll see if I can make it understandable otherwise, but that term would be handy to describe it. So that already suggests it should be added.
well, the "main/bridge driver" is not the driver that controls the "media hardware complex"
(I guess we used hardware instead of device on our past discussions)
with regards to complex
it is the one that controls just the part of the hardware that contains the DMA bridge
maybe "DMA bridge driver"?
btw, I vagely remember we didn't reach any consensus with regards to "main driver"
so, this ended being dropped from the glossary
mchehab: On the main driver  --- it does, to some extent, control the media hardware complex.
At least the control to some extent goes through it.
That extent is lesser on MC-enabled drivers.
Things have also changed over time.
Power management has been largely removed from that scope.
mchehab: Shouldn't most API instances be replaced by uAPI? This is all about uAPI, but that could be explicit.
sailus: good point. yeah, it makes sense to me using uAPI within userspace-api/media
(on the other hand, it is already on a book named "userspace-api" - probably a little overkill
but it is just one additinal letter - it shouldn't hurt calling it uAPI everywhere there)
additinal -> additional
Ack. I'll do that while here...
it probably makes a lot more sense to use uAPI/kAPI at the driver-api/media book
(if/where the API term is used)
$ git grep API Documentation/driver-api/media/|wc -l
104
Oh well.
Perhaps this requires more thought, whether it's making sense. I'll skip that for now at least.
pinchartl: Yeah, V4L2_CID_CAPTURE_TRIGGER seems nice.
mchehab: sailus: regarding "main driver", how about "primary driveR"?
good that the parallel ATA days are over