Re: [PATCH v2 00/12] Media Controller capture driver for DM365
From: Sakari Ailus
Date: Fri Nov 23 2012 - 08:57:46 EST
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@xxxxxx> 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@xxxxxx>
> >>
> >> 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?
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/