There is now the driver for the TC358743 in mainline, but my stumbling
block is finding a useful example of how to actually use it. The commit
text by Mats Randgaard says it was "tested on our hardware and all the
implemented features works as expected", but I don't know what that
hardware was or how it was used.
It's for Cisco video conferencing equipment, but it basically boils down to
capturing HDMI input over a CSI2 bus. I believe it's on an omap4.
I know Philip Zabel also developed for the TC358743. Philip, do you have a
git tree available that shows how it is used?
The media controller API seems to be part of the answer, but that seems
to be a large overhead for an application to have to connect together
multiple sub-devices when it is only interested in images out the back.
The MC is only needed if you have hardware that allows for complex and/or
dynamic internal video routing. For a standard linear video pipeline it
is not needed.
Is there something that sets up default connections that I'm missing?
Somewhere within device tree?
Typically the bridge driver (i.e. the platform driver that sets up the
pipeline and creates the video devices) will use the device tree to find
the v4l2-subdevice(s) it has to load and hooks them into the pipeline.
drivers/media/platform/am437x/am437x-vpfe.c looks to be a decent example
of that.
Of course, if you have more complex pipelines, then you need to support
the MC.
I have looked at the OMAP4 ISS driver as a vaguely similar device, but
that seemingly covers the image processing pipe only, not hooking in to
the sensor drivers.
Sensor drivers are hooked in in function iss_register_entities(), see the
section for "/* Register external entities */".
I've also got a slight challenge in that ideally I want the GPU to
allocate the memory, and ARM map that memory (we already have a service
to do that), but I can't see how that would fit in with the the existing
videobuf modes. Any thoughts on how I might be able to support that? The
existing V4L2 driver ends up doing a full copy of every buffer from GPU
memory to ARM, which isn't great for performance.
There may be an option to use contiguous memory and get the GPU to map
that, but it's more involved as I don't believe the supporting code is
on the Pi branch.
The proper way to do this is that the GPU can export buffers as a DMABUF file
descriptor, then import them in V4L2 (V4L2_MEMORY_DMABUF). The videobuf2
v4l2 framework will handle all the details for you, so it is trivial on
the v4l2 side.
If the GPU doesn't support dmabuf, then I'm not sure if you can do this
without horrible hacks.
Regards,
Hans
Any help much appreciated.
Thanks.
Dave
PS If those involved in the TC358743 driver are reading, a couple of
quick emails over the possibility of bringing the audio in over CSI2
rather than I2S would be appreciated. I can split out the relevant CSI2
ID stream, but have no idea how I would then feed that through the
kernel to appear via ALSA.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
