bbrezillon: thanks for the RFC. I will likely not have time to review it before the 15th though
neg: Hejssan!
hverkuil: just resent the H264 patches
you can discard the v6, I forgot to update the patch series number
the v7 is the one you want to look at
I did send a reply, but it hasn't shown up yet.
ah. now it arrived.
sailus: hej
hverkuil: i'll send a v8 right away, thanks !
mripard: sorry about that one, but the inconsistent names are too confusing :-)
hverkuil: don't worry, it's a pretty big patch so it's easy to have something like that sneak in during reviews :)
sailus: reviewed your patch series.
sailus: I'm not sure to understand what you're trying to achieve (maybe I'm tired, but the cover letter is very cryptic), but "[RFC 4/8] omap3isp: Rework OF endpoint parsing" gets quite complicated
it would be nice to understand where you want to go
"It enables the use of
endpoint configuration defaults that is available sensors and other
drivers that only use a single endpoint."
(on my never-ending todo list: rewrite v4l2 async notifier completely)
pinchartl: no problem
pinchartl: oh, BTW, udmabuf seems to do the job
nice to hear
I can allocate dmabuf objs and pass them to a queue
how is memory allocated ?
it's backed by a memfd file
when I say it does the job, that's true at least for the vivid drivers :)
so no guarantee on alignment, fitness for DMA mapping, contiguous DMA and all that ?
nope
sounds like a very useful API...
what is it meant for ?
exchanges buffers between host and guest
that's what the commit message says
was developped for virgl
sounds like another half-baked API :-(
I don't think it's been designed as a "generic memory allocator that works for everything"
unfortunately :-/
is that even possible :P