From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753248Ab2KYQ1q (ORCPT ); Sun, 25 Nov 2012 11:27:46 -0500 Received: from mail-ob0-f174.google.com ([209.85.214.174]:41072 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753187Ab2KYQ1o (ORCPT ); Sun, 25 Nov 2012 11:27:44 -0500 MIME-Version: 1.0 In-Reply-To: <201211231501.52852.hverkuil@xs4all.nl> References: <1353077114-19296-1-git-send-email-prabhakar.lad@ti.com> <20121123135753.GB31879@valkosipuli.retiisi.org.uk> <201211231501.52852.hverkuil@xs4all.nl> From: Prabhakar Lad Date: Sun, 25 Nov 2012 21:57:23 +0530 Message-ID: Subject: Re: [PATCH v2 00/12] Media Controller capture driver for DM365 To: Hans Verkuil , Sakari Ailus , Laurent Pinchart Cc: LMML , LKML , DLOS , Manjunath Hadli , Prabhakar Lad , Mauro Carvalho Chehab Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Nov 23, 2012 at 7:31 PM, Hans Verkuil 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 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 >> > >> >> > >> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html