Hi Mchehab, We are very appreciating for your reply.
For GPL, We are agree to follow GPL license to open source code which is in Linux kernel. For "but we don't accept any other OS-dependent code", we can follow this rule to remove relative OS-dependent code. For " 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.", We can follow GPL, Our intention is not to be a copyright violation. What we hope to do is to separate our board support package to two part. One is driver part, another is platform part. We want to put driver part to kernel source folder driver/media, or driver/xxx and put platform part to arch/arm/mach-xxx. Both of those code will follow GPL license, and we want to upstream both into main Linux code line. Because our hardware is a consumerism orientation production, different hardware module is highly dependency to provide cost efficiency performance. It will cause our driver implement concept will have huge different with other company or personal computer. For this reason, we want to collect non-standard part implement to "platform", in our view this is a very low level / highly hardware dependency from our production to product. We also hope most of platform part can be re-use to another OS, it can reduce cost for quality assurance or sync of bug fix to different OS. We hope driver part can join and co-work with media community. Provide those driver part will reduce cost and time to upgrade to new version of kernel. For example, the model we expect is: User mode APP ==interface(V4L2)==> /driver/media/V4L2_Jpeg == interface(a kind of media platform, hope have standard)==> /arch/arm/mach-MTK-TV-model2/platform_jpeg -----Original Message----- From: Mauro Carvalho Chehab [mailto:mchehab+sams...@kernel.org] Sent: Tuesday, August 14, 2018 5:39 PM To: Jesse Huang (黃建興) <jesse.hu...@mstarsemi.com> Cc: mche...@kernel.org; linux-media@vger.kernel.org; Yishin Tung (童怡新) <yishin.t...@mstarsemi.com>; Zink Hsin (辛鴻杰) <zink.h...@mediatek.com>; MF Hsieh (謝明甫) <mf.hs...@mstarsemi.com>; Junyou Lin (林俊裕) <junyou....@mstarsemi.com> Subject: Re: Using big platform driver as foundation to implement TV driver framework in Linux 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
