Hi all. I've been porting an old driver to videobuf2 framework, but when compiling as external module it doesn't find vb2_dma_contig symbols. I see that my kernel doesn't have VIDEOBUF2_DMA_CONTIG enabled. How can I enable it?
inigo: easiest is to enable a driver that does need it.
Or patch the new driver into the kernel instead of building as an out-of-tree module.
sailus: I rebased my tree, saving the old master branch as a tag: old/cs_7e6b6b945272
the three patches without SOB from its author got removed
plus one fixup patch from me
please get the SOB from Alan Chiang <alanx.chiang@intel.com> on those patches:
c578c7710712 media: imx258: Add imx258 camera sensor driver
3a8fdc1426c3 media: dw9807: Add dw9807 vcm driver
2f9c1c88369f media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil
and don't forget to place this patch after them when re-submitting:
7e6b6b945272 (tag: old/cs_7e6b6b945272) media: dw9807: remove an unused var
mchehab: I've resubmitted the patches in question.
The fix is squashed to the dw9807 driver.
hverkuil: I'm getting this errors and I can't figure why
tvd tvd: coherent DMA mask is unset
tvd tvd: dma_alloc_coherent of size 622080 failed
this is in reqbufs
ttomov: Do you happen to have a driver that uses the new luma-only formats?
sailus: yes
Is the driver patch already on LMML?
it is not
The practice has been that new formats are only applied when the driver is there.
hopefully in a few weeks
Good.
we can delay that until the driver is sent, no problem
The patches seem sound, I'll mark them as deferred for now.
but it was good to have them reviewed
Or... perhaps just leave them as new.
Indeed.
Thanks.
thanks :)
mripard: Bonjour!
sailus: Moi!
Comment vas-tu?
you reached my limits in Finnish :)
:-D
I'd have a quick question on a matter unrelated to cameras.
pretty good otherwise, you?
I'm doing fine, too.
The weather is nice here.
nvmem --- there's an API to obtain a cell corresponding to a given cell name, but what would you do if there are more than one cell with the same name?
For nvmem consumers, that is.
Add a new function with index to tell which one to return?
as far as I remember, there's two layers of name
the one specific to the customer, and one global
pretty much like the clocks
so you can reference either the global name, or the consumer specific one
in your case, you should have two different consumer names, pointing possibly to the same cell
The case is that there would be two EEPROM devices that would contain content to be used for the same purpose.
is it exactly the same data (redundancy) ?
or two different set of data for the same purpose?
Not the same data, but for the same purpose.
(like calibration of two different parts of a sensor)
Camera modules may have several EEPROMs.
I guess i'd call them "<$purpose>-<$target>" then
E.g. one on the sensor itself and another one in the module.
oh
And you may need both to fit all the data there.
so you want to use the data for the same purpose, with one having precedence over the otheR?
ok
Yes, exactly.
if the precedence is static, then I'd just overwrite the DT if that's an option
The preference could be defined based on the order they're introduced in OF or the content itself (i.e. version info).
if it's not, I guess you should see what the nvmem maintainer(s?) thinks about that
Uh, overwrite what?
the DT property
I think you'd need two cells to describe that.
As there are two nvmem providers.
if it's fixed, you just need the one that you will actually use
or I'm missing something?
Both may well be needed.
Say, if you have two 2 kiB EEPROMs and 3 kiB of data, you need both EEPROMs to make it fit.
ok
then yeah, you probably want to contact the maintainer
Ack.
I think I'll send an RFC or something to the list.
Merci!
I was the original author, but I've not been really involved since, so I'm not really the more up-to-date on this
you're welcome :)
Yes, fair enough.
I'll send an RFC.
hverkuil: ping