Hi Jesse,
Em Mon, 13 Aug 2018 01:32:45 +0000
Jesse Huang (黃建興) <jesse.hu...@mstarsemi.com> escreveu:
> Hi Mchehab,
> Hi Linux-Media,
>
> MTK/MStar try to move TV SOC proprietary driver framework to Linux TV driver.
>
> But, we also need to share/re-use driver code to non-OS which is a size
> limitation low cost system.
>
> Normally, each Linux driver need to control registers directly by it self.
> For example:
> ===============================(sample code begin)
> linux-3.18-exynos7270-sandbox.opensw0312.rebase-3d91408\drivers\media\pci\cx25821\cx25821-video.c
> static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type
> i)
> {
> struct cx25821_channel *chan = video_drvdata(file);
>
> if (i != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> return -EINVAL;
>
> if (chan->streaming_fh && chan->streaming_fh != priv)
> return -EBUSY;
> chan->streaming_fh = priv;
>
> return videobuf_streamon(&chan->vidq);
> }
> ===============================(sample code end)
>
>
>
> But, in our concept, we hope to provide an entire proprietary a driver as a
> “MTK TV platform driver”. Base on this driver to implement Linux standard TV
> driver.
> If will look like this:
> ===============================(sample code begin)
> static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type
> i)
> {
> return mtk_tv_platform->video->streamon();
> }
>
> The mtk_tv_platform will be register when setup_arch()
> void __init setup_arch(char **cmdline_p)
> {
> return platform_device_register(&mtk_tv_platform);
> }
> ===============================(sample code end)
>
> Would this kid of implement method can be accept for Linux upstream/submit
> driver rule? What kind of framework design guide line/rule we should follow?
> Would it possible to have some reference for us.
>
> If this method is possible, we can share a lot of human resource to both
> maintain for Linux and non-Linux project.
Not sure if I understand what you want to do.
The Linux Kernel is under a GPL version 2 license, meaning that
anyone wanting to do Kernel development should license their work
under those terms.
In other words, If you want to submit a driver to the Linux Kernel, the
needed software to control the hardware should all be upstreamed using
GPL version 2, including all register settings.
In the specific case of image enhancement algorithms, like 3A, we're
currently working on a solution that would allow a third party software
(ideally open source, but it could be a binary code) to run on
userspace, receiving metadata from the hardware via a documented
userspace, and using the standard V4L2 API to adjust the hardware,
after doing some (usually proprietary) processing.
So, if you're willing to contribute under this terms, we can help you.
It could still be possible to share code with other OS, depending on
how you write the driver, but we don't accept any other OS-dependent
code (like #ifdefs inside Linux). What other vendors usually do is
to either encapsulate the other-os dependent part on a different
source file (not submitted to Linux) or to internally have some
sort of process to strip #ifdefs when submitting drivers to Linux.
If otherwise all you want is to have a wrapper driver to run some
proprietary driver, then shipping such solution would likely be a
copyright violation and we can't help you.
Thanks,
Mauro
