Re: [PATCH v2 00/12] Media Controller capture driver for DM365
HI Sakari, On Mon, Nov 26, 2012 at 5:58 AM, Sakari Ailus wrote: > > Hi Prabhakar, > On Sun, Nov 25, 2012 at 09:57:23PM +0530, Prabhakar Lad wrote: >> On Fri, Nov 23, 2012 at 7:31 PM, Hans Verkuil wrote: >> > On Fri November 23 2012 14:57:53 Sakari Ailus wrote: > ... >> >> 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 ? > > I'd put them to staging if they're related to the driver ifself rather than > e.g. resource definitions. What would go under arch/arm then? > I am targeting only the driver to get into 3.8 and not the machine changes for DM365. Regards, --Prabhakar > -- > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Prabhakar, On Sun, Nov 25, 2012 at 09:57:23PM +0530, Prabhakar Lad wrote: > On Fri, Nov 23, 2012 at 7:31 PM, Hans Verkuil wrote: > > On Fri November 23 2012 14:57:53 Sakari Ailus wrote: ... > >> 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 ? I'd put them to staging if they're related to the driver ifself rather than e.g. resource definitions. What would go under arch/arm then? -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
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 majord...@vger.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
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. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
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? -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
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 ? Regards, --Prabhakar Lad > -- > Kind regards, > > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
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. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Prabhakar and others, 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. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Prabhakar, 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 Many thanks for taking the driver this far! However, I feel that there's still some work to do, especially in the user space API. Some things could be implemented using the generic API but currently use davinci-specific API; private IOCTL is being used where controls would do, and resizing is enabled or disable explicitly in ipipeif configuration. Also, there are things such as internal clock frequencies visible in the API. I can go to more details soon after taking a closer look at the patches. If you wish to get this to mainline kernel fast, a viable option IMO would be the staging tree. What do you think? Cc Hans and Laurent. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi All, On Fri, Nov 16, 2012 at 8:15 PM, 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. > Attached is the ps file to give a clear picture of entity connections. Regards, --Prabhakar Lad > 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 > > Documentation/video4linux/davinci-vpfe-mc.txt| 154 ++ > drivers/media/platform/davinci/Kconfig | 11 + > drivers/media/platform/davinci/Makefile |3 + > drivers/media/platform/davinci/dm365_ipipe.c | 1863 +++ > drivers/media/platform/davinci/dm365_ipipe.h | 179 ++ > drivers/media/platform/davinci/dm365_ipipe_hw.c | 1048 +++ > drivers/media/platform/davinci/dm365_ipipe_hw.h | 559 ++ > drivers/media/platform/davinci/dm365_ipipeif.c | 1063 +++ > drivers/media/platform/davinci/dm365_ipipeif.h | 233 +++ > drivers/media/platform/davinci/dm365_isif.c | 2095 > ++ > drivers/media/platform/davinci/dm365_isif.h | 203 +++ > drivers/media/platform/davinci/dm365_isif_regs.h | 294 +++ > drivers/media/platform/davinci/dm365_resizer.c | 1999 + > drivers/media/platform/davinci/dm365_resizer.h | 244 +++ > drivers/media/platform/davinci/vpfe_mc_capture.c | 741 > drivers/media/platform/davinci/vpfe_mc_capture.h | 97 + > drivers/media/platform/davinci/vpfe_video.c | 1620 + > drivers/media/platform/davinci/vpfe_video.h | 155 ++ > drivers/media/platform/davinci/vpss.c| 59 + > include/media/davinci/vpfe.h | 86 + > include/media/davinci/vpss.h | 16 + > include/uapi/linux/Kbuild|2 + > include/uapi/linux/davinci_vpfe.h| 1285 + > include/uapi/linux/dm365_ipipeif.h | 93 + > 24 files changed, 14102 insertions(+), 0 deletions(-) > create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt > create mode 100644 drivers/media/platform/davinci/dm365_ipipe.c > create mode 100644 drivers/media/platform/davinci/dm365_ipipe.h > create mode 100644 drivers/media/platform/davinci/dm365_ipipe_hw.c > create mode 100644 drivers/media/platform/davinci/dm365_ipipe_hw.h > create mode 100644 drivers/media/platform/davinci/dm365_ipipeif.c > create mode 100644 drivers/media/platform/davinci/dm365_ipipeif.h > create mode 100644 drivers/media/platform/davinci/dm365_isif.c > create mode 100644 drivers/media/platform/davinci/dm365_isif.h > create mode 100644 drivers/media/platform/davinci/dm365_isif_regs.h > create mode 100644 drivers/media/platform/davinci/dm365_resizer.c > create mode 100644 drivers/media/platform/davinci/dm365_resizer.h > create mode 100644 drivers/media/platform/davinci/vpfe_mc_capture.c > create mode 100644 drivers/media/platform/davinci/vpfe_mc_capture.h > create mode 100644 drivers/media/platform/davinci/vpfe_video.c > create mode 100644 drivers/media/platform/davinci/vpfe_video.h > create mode 100644 include/media/davinci/vpfe.h > create mode 100644 include/uapi/linux/davinci_vpfe.h > create mode 100644 include/uapi/linux/dm365_ipipeif.h > > -- > 1.7.4.1 > graph.ps Description: PostScript document
