| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 25 Nov 2012 21:57:23 +0530 From: Prabhakar Lad <prabhakar.csengg@...il.com> To: Hans Verkuil <hverkuil@...all.nl>, Sakari Ailus <sakari.ailus@....fi>, Laurent Pinchart <laurent.pinchart@...asonboard.com> Cc: LMML <linux-media@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, DLOS <davinci-linux-open-source@...ux.davincidsp.com>, Manjunath Hadli <manjunath.hadli@...com>, Prabhakar Lad <prabhakar.lad@...com>, Mauro Carvalho Chehab <mchehab@...radead.org> Subject: Re: [PATCH v2 00/12] Media Controller capture driver for DM365 Hi, On Fri, Nov 23, 2012 at 7:31 PM, Hans Verkuil <hverkuil@...all.nl> wrote: > On Fri November 23 2012 14:57:53 Sakari Ailus wrote: >> Hi Prabhakar, >> >> On Fri, Nov 23, 2012 at 06:51:28PM +0530, Prabhakar Lad wrote: >> > Hi Sakari, >> > >> > On Fri, Nov 23, 2012 at 6:43 PM, Sakari Ailus <sakari.ailus@....fi> wrote: >> > > Hi Prabhakar and others, >> > > >> > > (Just resending; Laurent's e-mail address corrected, cc Hans, too.) >> > > >> > > On Fri, Nov 16, 2012 at 08:15:02PM +0530, Prabhakar Lad wrote: >> > >> From: Manjunath Hadli <manjunath.hadli@...com> >> > >> >> > >> This patch set adds media controller based capture driver for >> > >> DM365. >> > >> >> > >> This driver bases its design on Laurent Pinchart's Media Controller Design >> > >> whose patches for Media Controller and subdev enhancements form the base. >> > >> The driver also takes copious elements taken from Laurent Pinchart and >> > >> others' OMAP ISP driver based on Media Controller. So thank you all the >> > >> people who are responsible for the Media Controller and the OMAP ISP driver. >> > >> >> > >> Also, the core functionality of the driver comes from the arago vpfe capture >> > >> driver of which the isif capture was based on V4L2, with other drivers like >> > >> ipipe, ipipeif and Resizer. >> > >> >> > >> Changes for v2: >> > >> 1: Migrated the driver for videobuf2 usage pointed Hans. >> > >> 2: Changed the design as pointed by Laurent, Exposed one more subdevs >> > >> ipipeif and split the resizer subdev into three subdevs. >> > >> 3: Rearrganed the patch sequence and changed the commit messages. >> > >> 4: Changed the file architecture as pointed by Laurent. >> > >> >> > >> Manjunath Hadli (12): >> > >> davinci: vpfe: add v4l2 capture driver with media interface >> > >> davinci: vpfe: add v4l2 video driver support >> > >> davinci: vpfe: dm365: add IPIPEIF driver based on media framework >> > >> davinci: vpfe: dm365: add ISIF driver based on media framework >> > >> davinci: vpfe: dm365: add IPIPE support for media controller driver >> > >> davinci: vpfe: dm365: add IPIPE hardware layer support >> > >> davinci: vpfe: dm365: resizer driver based on media framework >> > >> davinci: vpss: dm365: enable ISP registers >> > >> davinci: vpss: dm365: set vpss clk ctrl >> > >> davinci: vpss: dm365: add vpss helper functions to be used in the >> > >> main driver for setting hardware parameters >> > >> davinci: vpfe: dm365: add build infrastructure for capture driver >> > >> davinci: vpfe: Add documentation >> > > >> > > As discussed, here's the todo list for inclusion to staging. >> > > >> > > - User space interface refinement >> > > - Controls should be used when possible rather than private ioctl >> > > - No enums should be used >> > > - Use of MC and V4L2 subdev APIs when applicable >> > > - Single interface header might suffice >> > > - Current interface forces to configure everything at once >> > > - Get rid of the dm365_ipipe_hw.[ch] layer >> > > - Active external sub-devices defined by link configuration; no strcmp >> > > needed >> > > - More generic platform data (i2c adapters) >> > > - The driver should have no knowledge of possible external subdevs; see >> > > struct vpfe_subdev_id >> > > - Some of the hardware control should be refactorede >> > > - Check proper serialisation (through mutexes and spinlocks) >> > > - Names that are visible in kernel global namespace should have a common >> > > prefix (or a few) >> > > >> > > This list likely isn't complete, but some items such as the locking one is >> > > there simply because I'm not certain of the state of it. >> > > >> > Thanks a lot. I'll include this TODO's in documentation patch itself, >> > But I am not sure if the driver is going in staging, the documentation >> > file would still be present under Documentation directory or even >> > this should go in staging directory itself ? >> >> I think it should go under staging, the same directory as the driver. >> >> Hans, Mauro: could you confirm this? > > I agree with that, that way things stay together in one directory. > Ok I'll have the documentation in staging folder itself. What about the header file which is added to include/media/davinci/xxx.h, these header files are used by machine file and drivers only, I think also moving them to staging wont make sense and also these files are expected not to change, what are your suggestion on this ? Regards, --Prabhakar Lad > Regards, > > Hans > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists